Installation nicht machbar weil Passwort verunstaltet wird?

[Wisi]

Eigentlich wollte ich den BUG melden, aber finde einfach nicht den Button... Wenn ich auf "Fehler melden" klicke sehe ich nur die Fehler, und kann kein neuen melden. Nunja vielleicht jemand mit Ahnung den Fehler melden?

Also wenn man bei der Installation zur Datenbank Zugangsdaten Maske ankommt und ein Passwort hat welches nur aus Nummern besteht, und dann auch noch eine 0 am Anfang hat, dann konvertiert TypoLight das PW in ein anderes Zahlensystem um somit ist die installation unmöglich.

Beispiel 0345 wird zu 11 oder so. (nicht wahr, nur ein Beispiel)

[xtra]

Beispiel 0345 wird zu 11 oder so. (nicht wahr, nur ein Beispiel)

Ja, da bin ich auch schon ein paar mal reingefallen.
Seither vermeide ich solche Passwoerter.

Gruss
Chris

[marcules]

Beispiel 0345 wird zu 11 oder so. (nicht wahr, nur ein Beispiel)

Das hat schon seine Richtigkeit, denn Zahlen werden als solche erkannt und in der Datenbank korrekt abgespeichert. Siehe dazu:

http://https://contao.org/issues/286


Ein ganz leichter Bugfix wäre, wie xtra schon erwähnt hat, einfach ein anderes Passwort zu wählen, welches KEINE Zahl als solches ist. (Achtung auch e ist eine Repräsentation einer Zahl ^^)



Grüße,

Marc

[Wisi]

Jaa BlaBla kein Bug Bla Bla... Schon klar das es Logisch richtig ist, aber eben nicht in diesem Kontext. Warum sollte das bitteschön RICHTIG sein? Wenn es nicht geht dann gehts nicht! Dann macht phpBB wohl was falsch, den da ging das Passwort weil es direkt als Zeichenkette und nicht als Zahl interpretiert wurde.

Und wie man das Problem behebt sollte auch jedem Klar sein. Nur Passwort ändern ist nicht, wenn da schon mehrere Kundenprojekte drauf laufen. Ich hab das Passwort einfach direkt in die install datei reingepackt und dann ging es.

[xtra]

Jaa BlaBla kein Bug Bla Bla... Schon klar das es Logisch richtig ist, aber eben nicht in diesem Kontext. Warum sollte das bitteschön RICHTIG sein? Wenn es nicht geht dann gehts nicht! Dann macht phpBB wohl was falsch, den da ging das Passwort weil es direkt als Zeichenkette und nicht als Zahl interpretiert wurde.

Da muss unsere Ironie wohl gaenzlich untergegangen sein. Entschuldige bitte.
Wir sehen das so wie Du, es macht in diesem Kontext keinen Sinn, wurde aber schon mal in aehnlicher Form als Bug gemeldet und als "invalid" deklariert. Somit ist es kein anerkannter Bug und wird vermutlich auch nicht geaendert werden.

Und wie man das Problem behebt sollte auch jedem Klar sein. Nur Passwort ändern ist nicht, wenn da schon mehrere Kundenprojekte drauf laufen. Ich hab das Passwort einfach direkt in die install datei reingepackt und dann ging es.

Ja, so geht es auch, aber Vorsicht walten lassen, beim speichern der Einstellungen im Backend. Es koennte passieren, dass das Passwort wieder anders gespeichert wird und du dann deine localconfig.php jedesmal anpassen musst.
Alternative ist, das Passwort hardcodiert unterhalb von "INSTALL SCRIPT STOP" in der localconfig nochmals anzufyhren, damit es an dieser Stelle ein ggf. wieder numerisches yberschreibt (Der Bereich nach dem STOP wird von TYPOlight nicht mehr veraendert).

Gruss
Chris

[xchs]

Eigentlich wollte ich den BUG melden, aber finde einfach nicht den Button... Wenn ich auf "Fehler melden" klicke sehe ich nur die Fehler, und kann kein neuen melden. Nunja vielleicht jemand mit Ahnung den Fehler melden?

Da Du ja jetzt "Ahnung" hast, kannst Du gerne im Ticketsystem von TYPOlight ein entsprechendes Fehlerticket einstellen. Dafür ist allerdings eine Registrierung notwendig; den Link findest Du ganz oben rechts.

[xtra]

Da Du ja jetzt "Ahnung" hast, kannst Du gerne im Ticketsystem von TYPOlight ein entsprechendes Fehlerticket einstellen. Dafür ist allerdings eine Registrierung notwendig; den Link findest Du ganz oben rechts.

Du hast das oben verlinkte Ticket wohl ybersehen.
Das wurde schon einmal (in aehnlicher Form) im Tracker gemeldet, jedoch als invalid abgelehnt. Von daher wyrde ein neues Ticket aller Wahrscheinlichkeit als duplicate ebenfalls abgelehnt werden.

[dl1ely]

Ähm, das kann ja wohl nicht wahr sein...

Da wird ein eindeutiger Bug als "Ist wohl kein guter Name für eine Datenbank" abgetan? Krass. Demnächst funktioniert TL nurnoch, wenn ganz bestimmte Schemata für Benennungen eingehalten werden ("Jeder Datenbank- und Feldname muss mit 'INetRobots' anfangen"), alles andere sind dann halt "schlechte Namen"?

Vielleicht sollte man eine neue Ticketkategorie "Ist ein Bug, aber interessiert mich nicht" einführen...

Stefan

[christian]

Da wird ein eindeutiger Bug als "Ist wohl kein guter Name für eine Datenbank" abgetan? Krass. Demnächst funktioniert TL nurnoch, wenn ganz bestimmte Schemata für Benennungen eingehalten werden

Das ist bereits so und funktioniert prima. Ohne Präfix "tl_" dürftest Du z.B. ziemliche Probleme haben, die Datenbank zum Laufen zu bekommen
Etliche Extensions verlangen auch spezielle Benennungen für diverse Dinge. Das ist doch absolut ok so.
Ich gehe sogar mal einen Schritt weiter: Wenn sich ein "Fehler" durch einen einfachen Workaround oder ein bestimmtes Verhalten abstellen lässt, aber - aus welchen Gründen auch immer - viel Arbeit bei der Beseitigung machen würde: Laß ihn drin und gut.
Du bekommst hier ein sehr ausgereiftes System kostenfrei zur Verfügung gestellt, hast auch noch die Möglichkeit zur jederzeitigen Ticketerstellung und posaunst dann in einem derartigen Ton "Forderungen" hier rein?? Mach's doch selbst.

@Wisi:
Bevor man diverse Kundenprojekte darauf laufen hat, sollte man sich informieren. Und wenn's daneben gegangen ist: Deine Kunden werden es überleben, ein neues Passwort zu notieren.
BTW: Projekte von verschiedenen Kunden in 1 TL-Installation können auch irgendwann zu bösen Nebenwirkungen führen - such mal hier im Forum danach.

Vielleicht sollte man eine neue Ticketkategorie "Ist ein Bug, aber interessiert mich nicht" einführen...

Definitiv! Alleine, um eine Heimat für derartige Beiträge zu haben.

Grüße,

Christian

[dl1ely]

Das ist bereits so und funktioniert prima. Ohne Präfix "tl_" dürftest Du z.B. ziemliche Probleme haben, die Datenbank zum Laufen zu bekommen
Etliche Extensions verlangen auch spezielle Benennungen für diverse Dinge. Das ist doch absolut ok so.

Etwas andere Ebene. Finde ich als Vergleich ungeeignet.

Ich gehe sogar mal einen Schritt weiter: Wenn sich ein "Fehler" durch einen einfachen Workaround oder ein bestimmtes Verhalten abstellen lässt, aber - aus welchen Gründen auch immer - viel Arbeit bei der Beseitigung machen würde: Laß ihn drin und gut.

Das sagst du solange, bis du in ein Feld einen Hex-Wert eingeben musst, der blöderweise nur Zahlen und "E" enthält. Dann nützt dir "Das ist aber ein ungünstiger Wert, den du da gerade eingeben willst" nicht so viel.

Ich weiß nicht, wie viel Arbeit es bedeutet, den Bug zu fixen. Aber ich habe Verständnis dafür, wenn es nicht im Verhältnis steht, das dann kommuniziert und dokumentiert wird. Aber Antworten in Richtung (überspitzt) "Da hast du Pech gehabt", "Du hast das System nicht verstanden" oder ähnlich finde intransparent. Dann soll man klar sagen: "OK, da ist ein Problem, aber eine Lösung passt nicht mit vertretbarem Aufwand ins Konzept. Ein Workaround ist:...".

So würde ICH das gut und fair gegenüber den Anwendern und vor allem Ticketerstellern sehen. Inzwischen spart man sich doch, bestimmte Dinge überhaupt ins Ticketsystem einzustellen, weil man eh schon weiß oder vermutet, dass man mit einem unkonstruktiven Spruch abgewatscht wird. Klar, das muss man sich gefallen lassen, man ist ja "nur" User einer kostenfreien Software - aber gut finden muss man das nicht, oder?

Du bekommst hier ein sehr ausgereiftes System kostenfrei zur Verfügung gestellt, hast auch noch die Möglichkeit zur jederzeitigen Ticketerstellung und posaunst dann in einem derartigen Ton "Forderungen" hier rein?? Mach's doch selbst.

Das "mach doch selbst"-Argument kommt mir hier in den Diskussionen ein bisschen oft. Klar, kann ich machen. Forken und los gehts. Oder ich patche mir selbst was zusammen, und muss das bei jedem Update halt nachziehen. Aber darauf zielt es doch garnicht.

Im übrigen "fordere" ich nicht. Ich FORDERE nicht, dass der Bug behoben wird. Ich frage mich aber, wie der Umgang mit gemeldeten Bugs auf potentielle (insbesondere kommerzielle) Interessenten an Typolight wirkt. Schließlich ist das hier ein Projekt, mit dem einige Leute ihren Lebensunterhalt verdienen. Nicht nur als Core-Entwickler, sondern auch im Ökosystem drumherum.

Und einige Antworten auf Bug-Tickets finde ich persönlich einfach unprofessionell. Die Meinung kann man teilen, kann man nicht teilen, ...im Endeffekt muss Leo damit klar kommen. Es ist eine freie Welt.

Die Tatsache, dass TL aber ein GPL-Projekt ist darf meiner Meinung nach nicht bedeuten, dass Kritik an Abläufen oder Code verboten ist. Wenns mir zu viel wird, dann gehe ich, kein Thema. Aber ich hoffe, hier wird noch etwas außer Jubelstürmen geduldet - das würde auch zur freien Welt gehören.

@Wisi:
Bevor man diverse Kundenprojekte darauf laufen hat, sollte man sich informieren. Und wenn's daneben gegangen ist: Deine Kunden werden es überleben, ein neues Passwort zu notieren.

Wo kann man sich denn über dieses Verhalten informieren? In der Doku steht dazu nix.

Definitiv! Alleine, um eine Heimat für derartige Beiträge zu haben.

Schade, dass du dich auf dieses Niveau des Umgangs mit kritischen Meinungen herab begeben musst.

Grüße,

Christian

Viele Grüße,
Stefan

P.S.: Weiterhin von TYPOlight als Software-System begeistert...

[FloB]

Glaub mir, es gibt hier viele, die sich täglich über Eigenheiten von TYPOlight ärgern. Allerdings sind viele dieser Eigenheiten gewollt, um das System einfach zu halten – dagegen ist ja nichts einzuwenden, oder?

Das angesprochene Problem kommt so zustande: Die Input-Klasse validiert alle einkommenden Daten, auch das Passwort-Feld der Datenbank. Dabei wird mit is_numeric() geprüft, ob die Eingabe eine Zahl ist. Diese PHP-Funktion weiß aber nunmal nicht, dass man hier einen String erwartet / eingegeben hat, und castet somit die Eingabe auf Int / Float.

Eine Ausnahmebehandlung für bestimmte Felder einzubauen ist nicht praktikabel und nur in wenigen Fällen überhaupt vonnöten. Wenn du aber eine einfache Lösung findest, wären wir die alle sicherlich sehr dankbar!

[christian]

Gegen Kritik hat niemand etwas. Gegen Unzufriedenheit mit Abläufen und/oder Vorschläge auch nicht. Wenn ich aber so in den Wald reinrufe, muss ich mich nicht wundern, wenn der Wald zurückholzt.

Nichts für ungut. Gehen wir netter miteinander um, dann erledigt sich das. Zumal das eigentlich Problem nicht mal etwas ist, was der Aufregung lohnt.

Grüße,

Christian

[dl1ely]

Das angesprochene Problem kommt so zustande: Die Input-Klasse validiert alle einkommenden Daten, auch das Passwort-Feld der Datenbank. Dabei wird mit is_numeric() geprüft, ob die Eingabe eine Zahl ist. Diese PHP-Funktion weiß aber nunmal nicht, dass man hier einen String erwartet / eingegeben hat, und castet somit die Eingabe auf Int / Float.

Über welchen Code reden wir eigentlich gerade? Ich finde in system/libraries/Input.php (v2.8.1) ab Zeile 339 in Function xssClean:

		// Return if var is not a string
		if (is_bool($varValue) || is_null($varValue) || is_numeric($varValue))
		{
			return $varValue;
		}

Gecastet wird da nix. Mag ja sein, dass '1e3' als is_numeric() erkannt wird, aber trotzdem wird da '1e3' returned.

Sonst habe ich in der gesamten Input-Klasse keinen cast auf int gefunden.

Ein schneller grep liefert mir keine "verdächtigen" Casts nach int innerhalb der libraries und drivers-Unterverzeichnisse. Also keine Casts von Input-Parametern.

Wo versteckt sich der angebliche Cast?

Danke,
Stefan

OK, habe die Stelle gefunden, nach dem Studium des Tickets (sorry). Es geht garnicht um einen expliziten Cast, und es hat auch nix mit der Input-Klasse und der dort stattfindenen Validation zu tun. Ganz falsche Fährte. Die fragliche Stelle ist in Config.php, Zeile 286 (v2.8.1): Wenn is_numeric() ein true liefert, wird ein Config-Wert ohne Hochkommata in die Config-Datei geschrieben. Dort landet also durchaus noch korrekt "1e3". Beim Ausführen der Config-Datei liest PHP diesen Wert dann aber als "1000" ein.

Um das zu verhindern, müssten auch numerische Werte mit Hochkommata gespeichert werden, aber dann müssten die Werte vor Verwendung gecastet werden (wenn man weiss, dass es ein int ist).

Ohne grundlegendes Umkrempeln (z.B. Änderung der Policy darauf, alle Werte als Strings zu speichern, und bei Verwendung zu casten) wird das nicht zu ändern sein. Das Problem ist, dass das Escaping der Values aufgrund der Struktur der Values, und nicht aufgrund des "Typs" des Keys durchgeführt wird. Kann ich aber verstehen.

Das Problem besteht nicht nur beim "e" in der Zahl, sondern auch bei führenden Nullen.

Gut, dann kann das hier wohl geschlossen werden.

Stefan

[dl1ely]

Gegen Kritik hat niemand etwas. Gegen Unzufriedenheit mit Abläufen und/oder Vorschläge auch nicht. Wenn ich aber so in den Wald reinrufe, muss ich mich nicht wundern, wenn der Wald zurückholzt.

Gut, alles klar :-).

Stefan

[xtra]

Ein Konstrukt in der Art von:

// Return if var is not a string
if (is_bool($varValue) || is_null($varValue) || ((string)(float)$varValue === (string)$varValue) || (string)(int)$varValue === (string)$varValue))
{
    return $varValue;
} 

Koennte das Problem evtl. beheben (Achtung, ungetesteter, unschoener, experimenteller Code - Nicht zur Verwendung sondern nur als PoC zu verstehen).
Es geht primaer darum, dass die Werte nicht in Integer converted werden sondern explizit auf float/int und anschliessend wieder auf string gewandelt werden und dann das Ergebnis verglichen wird.
Der Wert bleibt dann ein String aber passiert den Vergleich, da er ein numerischer String ist.

Gruss
Chris

[dl1ely]

Geht solange gut, bis WIRKLICH jemand den numerischen Parameter 1000 als 1e3 eingibt, dieser als

$intVal = '1e3'; 

in der Config-Datei steht, und der Code z.B. bei

$intVal = $intVal+2; 

auf die Nase fällt.

Das Problem ließe sich nur lösen, wenn

• Config.php "weiss", welcher Parameter numerisch oder String ist
• Der Core und jede Extension Werte aus config.php vor Verwendung als Int auf int casten würde.
• man deinen Code verwendet und die scientific notation bei der Eingabe verbieten würde, d.h. 1e3 kein zulässiger numerischer Wert wäre (also schon bei der Validation im Input-Feld)

Die ersten beiden Punkte sind mit unverhältnismäßig großem Aufwand verbunden.

Der dritte wohl nicht, aber für ein Problem dieser Größenordnung wohl immernoch zu weitgehend als Fix.

Stefan

[FloB]

Es geht garnicht um einen expliziten Cast, und es hat auch nix mit der Input-Klasse und der dort stattfindenen Validation zu tun. Ganz falsche Fährte. Die fragliche Stelle ist in Config.php, Zeile 286 (v2.8.1): Wenn is_numeric() ein true liefert, wird ein Config-Wert ohne Hochkommata in die Config-Datei geschrieben. Dort landet also durchaus noch korrekt "1e3". Beim Ausführen der Config-Datei liest PHP diesen Wert dann aber als "1000" ein.

Nein, es ist kein expliziter Cast, sondern einer, der im PHP-Core durchgeführt wird. is_numeric() liefert zwar ein true/false zurück, aber modifiziert glaube ich trotzdem die Variable. Man müsste einfach mal einen kleinen Test mit gettype() nach is_numeric() fahren.

[deerwood]

Moin,

... is_numeric() liefert zwar ein true/false zurück, aber modifiziert glaube ich trotzdem die Variable.

Definitiv NICHT, siehe PHP-Doku. In Config::escape() werden Werte, die numerisch/bool aussehen "einfach so" zurückgeliefert und dann ungequoted in die localconfig.php geschrieben. Alles andere wird aufbereitet und der String-Wert wird ausdrücklich in single quotes eingekleidet, die dann auch so in localconfig.php landen.

Die Methoden Config::add() bzw. Config::update() bekommen Key und Value als Parameter und könnten so gezielt Sonderbehandlungen für bestimmte Config-Settings machen (etwa, wenn der Key = 'dbPass' ist). Config::ecape() wird dagegen aus Methode add() nur noch mit dem Wert aufgerufen und kann so nur noch diesen analysieren. Für String-Passworte hat escape() auch noch das Problem, dass z.B. 2 oder mehr aufeinander folgende Leerzeichen zu einem einzigen verkürzt werden.

Ein, in meinen Augen einfacher, Fix wäre, dass ein case Konstrukt in Config::add() für bestimmte Keys die Methode escape() mit einem zusätzlichen Flag aufruft, das anzeigt, dass es sich definitiv um einen String handelt, der nicht zu modifizieren ist (ausser eventuelle single quotes mit einem Backslash zu schützen).

--- .../system/libraries/Config.php.ORG    So 21. Feb 01:24:34 2010
+++ .../system/libraries/Config.php    Sa 13. Mrz 02:36:20 2010
@@ -249,7 +249,20 @@
     public function add($strKey, $varValue)
     {
         $this->blnIsModified = true;
-        $this->arrData[$strKey] = $this->escape($varValue) . ';';
+        $blnIsRawString = false;
+        switch ($strKey)
+        {
+            // TODO: add more keys here, if neccessary ...
+            case 'dbUser':
+            case 'dbPass':
+            case 'dbDatabase':
+                $blnIsRawString = true;
+                break;
+
+            default:
+                break;
+        }
+        $this->arrData[$strKey] = $this->escape($varValue, $blnIsRawString) . ';';
     }
 
 
@@ -279,10 +292,17 @@
     /**
      * Escape a parameter depending on its type and return it
      * @param mixed
+     * @param boolean
      * @return mixed
      */
-    protected function escape($varValue)
+    protected function escape($varValue, $blnIsRawString = false)
     {
+        if ($blnIsRawString)
+        {
+            // TODO: eventually (e.g. for Passwords) also escape \n, \r and \t ??? Then use " instead of ' !
+            return "'" . str_replace("'", "\\'", $varValue) . "'";
+        }
+
         if (is_numeric($varValue))
         {
             return $varValue; 

Code ist ungetestet und irgendwie auch müßig, ich ernte auch fast nur 'invalid' Tickets.

LG, Georg

[leo]

Wie Stefan nach ausführlicher Analyse des Codes festgestellt hat, ist eine allgemeingültige Lösung nicht möglich (deswegen wurde das Ticket auch geschlossen). Allerdings könnte man streiten, welcher Fall wohl öfter vorkommen: Dass jemand ein Passwort in der Art "1e3" eingibt oder dass jemand die Zahl 1000 als "1e3" eingibt. Daher könnten wir uns darauf einigen, dass alle Eingaben, die ein "e" enthalten, zukünftig als String interpretiert werden.

Das löst das Problem mit den "korrupten" DB-Namen, jedoch nicht das mit den führenden Nullen. Und es schafft ein neues "Problem", nämlich dass man Zahlen nicht mehr im Format "1e3" eingeben kann. Aber wie viele Nutzer machen das schon?

[Sebastian]

HI

Und es schafft ein neues "Problem", nämlich dass man Zahlen nicht mehr im Format "1e3" eingeben kann. Aber wie viele Nutzer machen das schon?

Gut zu wissen, dass so etwas überhaupt geht. Auf die Idee bin ich bisher nur bei meinem Taschenrechner gekommen…

Sebastian

[FloB]

Ich denke, die Möglichkeit is_numeric() bei bestimmten Einträgen zu umgehen, ist die praktikabelste. Damit kann man auch problemlos 1e3 und Konsorten verwenden.

[leo]

Ich bin da genau anderer Meinung. Für den Core ist es sicherlich kein Problem, eine Liste von Ausnahmen zu definieren. Die Extension-Entwickler hätten das Problem aber nach wie vor. Insofern halte ich das für wenig praktikabel.

[deerwood]

Moin,

Ich bin da genau anderer Meinung. Für den Core ist es sicherlich kein Problem, eine Liste von Ausnahmen zu definieren. Die Extension-Entwickler hätten das Problem aber nach wie vor. Insofern halte ich das für wenig praktikabel.

Ok, da habe ich nicht weit genug gedacht, der switch in meinem Beispiel ist zu unflexibel. Aber eine einfache Möglichkeit wäre, in .../system/config/config.php z.B.

$GLOBALS['TL_CONFIG']['RawStringSettingKeys'] = array('dbUser', 'dbPass', 'dbDatabase'); 

zu definieren und dann die Methode Config::add() so zu implementieren:

    public function add($strKey, $varValue)
    {
        $this->blnIsModified = true;
        $blnIsRawString =
            (is_array($GLOBALS['TL_CONFIG']['RawStringSettingKeys']) &&
             in_array($strKey, $GLOBALS['TL_CONFIG']['RawStringSettingKeys']))
            ? true
            : false;
        $this->arrData[$strKey] = $this->escape($varValue, $blnIsRawString) . ';';
    } 

Aud die Art würden auch Extension-Entwickler das Feature nutzen können.

// This is ...system/modules/some_extension/config/config.php
$GLOBALS['TL_CONFIG']['RawStringSettingKeys'][] = 'myKey'; 

LG, Georg

[leo]

Aber ist das nicht ungleich aufwändiger als mein Vorschlag?

if (is_numeric($varValue) && !preg_match('/e|^0+/', $varValue))
{
    return $varValue;
} 

Damit sind sowohl Eingaben im Format "1e3" als auch "00035" möglich. Lediglich wird "1e3" nicht mehr als "1000" interpretiert, aber wie viele Anwender nutzen diese Schreibweise? Müssen wir wirklich nur deswegen ein neues Config-Array definieren, den Core um eine Reihe von Ausnahmen ergänzen und alle Erweiterungen prüfen? Ich weiß ja nicht, was ihr unter "praktikabel" versteht, aber in meiner Welt fällt das nicht darunter

[Thomas]

Mal ganz ehrlich!
Mit was für Passwörten rechnet Ihr?

Ich nutze grundsätzlich, wo ich kann, cryptische Passwörter alla nM7646%$§nfeH79, wenn ich dort jetzt zufällig 1e3 eingebe, würde mein PW falsch interpretiert und würde mich vor leichte Probleme stoßen.

Der normale User denkt sogar noch einfacher und benutzt Namen, einfache Konstrukte oder zu kurze Passwörter, ohne auf den Sinn oder Unsinn einzugehen.

Die Null zu zu lassen wäre gut, gleichzeitig sollten aber auch Sonderzeichen möglich sein. Alles andere ist in meinen Augen kontraproduktiv (entwickelt sich langsam zu einer Art Lieblingswort ) und irritiert nur den Anwender.

Man sollte immer bedenken, dass nicht jeder ein verkappter Sicherheitsspezilist oder Sicherheitsvernatiker ist.

Ich gebe Euch Recht, das man einen gewissen Standard in den Köpfen der Nutzer erreichen sollte. Aber bitte nicht mit solchen Konstrukten, die nur Probleme in der Normalowelt verursachen würden.

[deerwood]

Moin Leo,

Aber ist das nicht ungleich aufwändiger als mein Vorschlag?

if (is_numeric($varValue) && !preg_match('/e|^0+/', $varValue))
{
    return $varValue;
} 

Sorry, ich hatte Deinen vorherigen Beitrag nicht als Vorschlag begriffen.

Ich gebe Dir Recht, Dein Ansatz ist "keep it simple, keep it running" bzw. pragmatisch. Große Zahlen-Eingaben im Backend macht kaum jemand mittels Exponential-Schreibweise. Die typischen großen Zahlen (86400 == 1 Tag, usw.) lassen sich mit Exponent nicht gut/zuverlässig eingeben.

Nimm es bitte als "Mitdenken", wenn auch nur in einem klein/klein Bereich.

Allerdings weise ich nochmals auf das Verändern von Leerzeichen-Ketten in Config::escape() hin. Und, wie Du an den TODO: Kommentaren in den Beispielen sehen kannst, habe ich keine gute Lösung für \n, \r und \t in Passwörtern.

LG, Georg

[dl1ely]

Ich hatte die Diskussion hier gar nicht mehr weiter verfolgt, sorry. Bin erst durch den 2.8.2-Release wieder drauf gestoßen. Danke für den Fix, und dass "wir" uns auf eine tragbare Lösung einigen konnten.

Super!

Stefan