input type password und chrome

[1211chef]

hi @all,

chrome lässt bei input type password keine änderungen zu, ist das ein bug? wenn ich value automatisch zuweisen möchte bleibt der alte wert drin stehen. hab gegurgelt aber find nix drüber. firefox und ie machen das anders. es schaut fast so aus als ob chrome den wert aus seinem eigenen speicher einliest und einen selbst zugewiesenen wert damit überschreibt.

das neue passwort wird schon korrekt übermittelt, aber value lässt sich beim einlesen nicht ändern.

<input type="password" name=\"pw\" value="$aus_der_datenbank">

weiß jemand was genaueres darüber?

gruss gustl

[Gunnar Bittersmann]

@@1211chef

weiß jemand was genaueres darüber?

Nein. Aber was ist das?

<input type="password" name=\"pw\" value="$aus_der_datenbank">

Das ist fehlerhaftes HTML und/oder fehlerhaftes PHP. htmlspecialchars() fehlt.

LLAP 🖖

[1211chef]

htmlspecialchars() fehlt.

ich geh mit sonderzeichen per script auf meine weise um. muss nicht alles nachmachen.

schönen feUerabend

[1unitedpower]

<input type="password" name=\"pw\" value="$aus_der_datenbank">

Das ist fehlerhaftes HTML und/oder fehlerhaftes PHP. htmlspecialchars() fehlt.

Das stimmt und das (finde ich) kann man keinem Programmierer zum Vorwurf machen. Kontextwechsel sind für Menschen nicht so leicht zu erkennen, für Maschinen jedoch schon. Eine hilfsbereite Programmiersprache stellt deshalb Sicherheitsmechanismen zur Verfügung, die diese Fehlerklasse kategorisch ausschließen. Das vermeidet riesige Sicherheitslücken und spart dazu noch eine Menge Schreibarbeit. PHP und die meisten objektorientierten Sprachen zählen leider nicht dazu. Unerklärlicherweise werden in PHP HTML-Ausgaben für gewöhnlich immernoch mit String-Konkatenation gebastelt. Wtf? Für eine Sprache, die im Web zu Hause ist.

[Der Martin]

Hallo,

<input type="password" name=\"pw\" value="$aus_der_datenbank">

Das ist fehlerhaftes HTML und/oder fehlerhaftes PHP. htmlspecialchars() fehlt.

Das stimmt und das (finde ich) kann man keinem Programmierer zum Vorwurf machen.

doch, unbedingt.

Kontextwechsel sind für Menschen nicht so leicht zu erkennen, für Maschinen jedoch schon.

Das sehe ich genau umgekehrt. Eine Maschine bzw. ein Programm kann nur im Ausnahmefall erkennen, was mit den erzeugten Ausgabedaten noch passieren soll und wird; ein Mensch, insbesondere wenn er sich Programmierer nennt oder als solcher tätig wird, sollte das können, weil er den Überblick nicht nur über das aktuelle Script, sondern über die Zusammenhänge im Projekt hat.

Eine hilfsbereite Programmiersprache stellt deshalb Sicherheitsmechanismen zur Verfügung, die diese Fehlerklasse kategorisch ausschließen. Das vermeidet riesige Sicherheitslücken und spart dazu noch eine Menge Schreibarbeit. PHP und die meisten objektorientierten Sprachen zählen leider nicht dazu.

PHP will Handwerkszeug sein, nicht eine komplette, auf ein bestimmtes Produkt ausgelegte Fertigungsstraße.

Unerklärlicherweise werden in PHP HTML-Ausgaben für gewöhnlich immernoch mit String-Konkatenation gebastelt.

Ja. PHP ist so angelegt, dass es über stdout und (meistens) HTTP genau die Zeichenfolge nachbildet, die der Client in diesem Kontext erwartet. Das ist wohl in den meisten Anwendungsfällen HTML-Quelltext, aber PHP will ja universell sein und nicht auf einen bestimmten Ressourcentyp festgelegt. Klar könnte man eine Scriptsprache auch so entwerfen, dass sie intern eine DOM-Struktur aufbaut, diese dann serialisiert und an den CLient liefert. Dann würde man sich aber die Flexibilität verscherzen, damit neben HTML auch mal Plaintext, CSS, generisches XML, JSON oder etwas ganz anderes zu erzeugen - etwa den binären Byte-Stream einer Bildressource.

Wtf? Für eine Sprache, die im Web zu Hause ist.

Tja. Spezialisierung schränkt meistens die möglichen Anwendungsbereiche ein. Ich bin ehrlich gesagt froh, dass man diesen Weg in PHP nicht gegangen ist.

So long,
 Martin

[1unitedpower]

Kontextwechsel sind für Menschen nicht so leicht zu erkennen, für Maschinen jedoch schon.

Das sehe ich genau umgekehrt. Eine Maschine bzw. ein Programm kann nur im Ausnahmefall erkennen, was mit den erzeugten Ausgabedaten noch passieren soll und wird; ein Mensch, insbesondere wenn er sich Programmierer nennt oder als solcher tätig wird, sollte das können, weil er den Überblick nicht nur über das aktuelle Script, sondern über die Zusammenhänge im Projekt hat.

Und inwiefern erleichtert es dem Programmierer die Arbeit, wenn er auch noch Lösungen zu Problemen entwickeln muss, die sich gar nicht stellen müssten?

Ein gutes Beispiel, wo PHP sich gebessert hat, ist die Datenbankschnittstelle, vergleiche die beiden Varianten:

mysql_query("select * from tablename where id = " . mysql_real_escape_string($id));

$db->prepare("select * from tablename where id = :id")->execute([":id" => $id]);

Im zweiten Fall, muss der Programmierer sich um den Kontextwechsel keine Gedanken machen, weil PDO ihn automatisch vornimmt. Das ist schon sehr viel besser, aber es erlaubt dem Programmierer leider immer noch die Query mit String-Konkatenation zusammenzubauen und dort einen Fehler zu machen.

Eine hilfsbereite Programmiersprache stellt deshalb Sicherheitsmechanismen zur Verfügung, die diese Fehlerklasse kategorisch ausschließen. Das vermeidet riesige Sicherheitslücken und spart dazu noch eine Menge Schreibarbeit. PHP und die meisten objektorientierten Sprachen zählen leider nicht dazu.

PHP will Handwerkszeug sein, nicht eine komplette, auf ein bestimmtes Produkt ausgelegte Fertigungsstraße.

Gutes Handwerkszeug sollte dem Programmier Arbeit abnehmen und nicht zusätzlich machen. Die Ausdrucksstärke einer Programmiersprache oder einer Schnittstelle zeichnet sich nicht dadurch aus, was man damit sagen kann, sondern was man nicht sagen muss ^[1].

Klar könnte man eine Scriptsprache auch so entwerfen, dass sie intern eine DOM-Struktur aufbaut, diese dann serialisiert und an den CLient liefert. Dann würde man sich aber die Flexibilität verscherzen, damit neben HTML auch mal Plaintext, CSS, generisches XML, JSON oder etwas ganz anderes zu erzeugen - etwa den binären Byte-Stream einer Bildressource.

String-Konkatenation ist doch völlig unflexibel und die Lösungen die man für eine Sprache wie HTML erarbeitet hat, kann man für CSS oder JSON doch erst recht nicht wiederverwenden. Das Zusammensetzen von Strings erfordert, dass der Programmierer strenge zeitliche Abfolgen in seinem Code einhält. Manuelle Kontextwechsel sorgen dafür, dass Lösungen nicht für verschiedene Einsatzgebiete wiederverwendet werden können. Der Programmierer muss sich jedes mal wieder um die selben nervigen Details des Zielformates scheren. Das ist der Produktivitätskiller und das Sicherheitsrisiko Nummer 1. Nur weil die selben primitiven Operationen immer wieder auftauchen, spricht das nicht für einen flexiblen Progammentwurf.

Wtf? Für eine Sprache, die im Web zu Hause ist.

Tja. Spezialisierung schränkt meistens die möglichen Anwendungsbereiche ein. Ich bin ehrlich gesagt froh, dass man diesen Weg in PHP nicht gegangen ist.

Ich redete nie von Spezialisierung... Obwohl ich finde, dass domänespezfische Sprachen hervorragend dazu geeignet sind robuste Lösungen für wiederkehrende Probleme zu basteln. PureScript hat beispielsweise eine eingebettete domänespezifische Sprache für HTML, das sieht dann so aus:

greet name = h1 $ text $ "Hello, " <> name <> "!"

Auch hier muss der Entwickler sich keine Gedanken darüber machen, ob die Variable name unter Umständen ein Sonderzeichen aus HTML enthält, weil die Funktion "text" einen Textknoten erzeugt.

Etwas bekannter dürfte JSX sein, eine Erweiterung von JavaScript um quasi-HTML-Syntax:

function greet (name) {
  return <h1>Hello, {name}!</h1>
}

Das ist weniger Schreibarbeit als in PHP und bietet eine echte Abstraktions-Schnittstelle.

---

1. In Anlehnung an "Readings in Artificial Intelligence and Databases". Dort fällt dieser Satz in Verbindung mit First-Order Logic. ↩︎

[Der Martin]

Hallo,

Kontextwechsel sind für Menschen nicht so leicht zu erkennen, für Maschinen jedoch schon.

Das sehe ich genau umgekehrt. Eine Maschine bzw. ein Programm kann nur im Ausnahmefall erkennen, was mit den erzeugten Ausgabedaten noch passieren soll und wird; ein Mensch, insbesondere wenn er sich Programmierer nennt oder als solcher tätig wird, sollte das können, weil er den Überblick nicht nur über das aktuelle Script, sondern über die Zusammenhänge im Projekt hat.

Und inwiefern erleichtert es dem Programmierer die Arbeit, wenn er auch noch Lösungen zu Problemen entwickeln muss, die sich gar nicht stellen müssten?

gar nicht - aber als guter[tm] Programmierer sollten einem derartige Routinegeschichten in Fleisch und Blut übergegangen sein, so dass man sie gar nicht mehr bewusst wahrnimmt, sondern einfach automatisch macht. Quasi aus dem Rückenmark, nicht mehr aus dem Großhirn. Ich vergleiche das mal mit einem guten Koch, der bei seiner Arbeit auch nicht mehr darüber nachdenkt, was da noch zum Abrunden oder Würzen in die Soße rein muss; er hat das im Gefühl.
Oder der Blick in den Rückspiegel im Auto: Das ist ein solcher Automatismus - ich weiß doch, dass das Bild seitenverkehrt ist, also lese ich Schriftzüge auch schon von rechts nach links, ohne dass es mir überhaupt bewusst wird. Und wenn dann ein Feuerwehr- oder Rettungswagen hinter mir ist, dessen Front gleich in Spiegelschrift bemalt ist, dann passt's wieder nicht.

Ein gutes Beispiel, wo PHP sich gebessert hat, ist die Datenbankschnittstelle, vergleiche die beiden Varianten:

mysql_query("select * from tablename where id = " . mysql_real_escape_string($id));

$db->prepare("select * from tablename where id = :id")->execute([":id" => $id]);

Als Softwareentwickler und Programmierer der alten Schule ist mir die erste Variante eingängiger und leichter zu überblicken. Aber das ist natürlich eine Frage der Gewöhnung.

Im zweiten Fall, muss der Programmierer sich um den Kontextwechsel keine Gedanken machen, weil PDO ihn automatisch vornimmt. Das ist schon sehr viel besser, aber es erlaubt dem Programmierer leider immer noch die Query mit String-Konkatenation zusammenzubauen und dort einen Fehler zu machen.

Natürlich. Wenn man um die Hilfestellungen einen Bogen macht, nützen sie einem nichts.

PHP will Handwerkszeug sein, nicht eine komplette, auf ein bestimmtes Produkt ausgelegte Fertigungsstraße.

Gutes Handwerkszeug sollte dem Programmier Arbeit abnehmen und nicht zusätzlich machen.

Ja. Ich will aber weder zwanzig einzelne Werkzeuge im Kasten haben, noch ein hochkomplexes Multifunktionstool - ich möchte ein paar wenige, möglichst einfache Werkzeuge haben, deren korrekte Handhabung gern auch etwas Übung voraussetzen darf. Ich weiß, ich bin da ein bisschen archaisch, aber das aus Überzeugung. ;-)

String-Konkatenation ist doch völlig unflexibel

Wenn letztendlich Text dabei herauskommen soll, ist sie IMO das flexibelste überhaupt.

Das Zusammensetzen von Strings erfordert, dass der Programmierer strenge zeitliche Abfolgen in seinem Code einhält.

Natürlich. Das setze ich voraus.

Wtf? Für eine Sprache, die im Web zu Hause ist.

Tja. Spezialisierung schränkt meistens die möglichen Anwendungsbereiche ein. Ich bin ehrlich gesagt froh, dass man diesen Weg in PHP nicht gegangen ist.

Ich redete nie von Spezialisierung...

Doch, gewissermaßen schon. Du hast implizit verlangt oder gewünscht, dass eine Sprache (wie hatten PHP als Beispiel) die Besonderheiten des Kontexts selbst erkennen und berücksichtigen solle. Das ist eine Spezialisierung; sie prädestiniert die Sprache dann für diesen speziellen Einsatzfall, macht sie aber für andere Fälle umständlich, im Extremfall unbrauchbar.

greet name = h1 $ text $ "Hello, " <> name <> "!"

Das sieht ja fast sp kryptisch aus wie Perl. ;-)

Etwas bekannter dürfte JSX sein, eine Erweiterung von JavaScript um quasi-HTML-Syntax:

function greet (name) {
  return <h1>Hello, {name}!</h1>
}

Auch das sieht syntaktisch irgendwie kaputt aus, wenn man es nicht kennt. Ein String ohne eindeutuge Stringbegrenzer verursacht bei mir leichte Übelkeit. Und wenn ich eine geschweifte Klammer in der Ausgabe haben möchte, müsste ich die diese vermutlich wieder escapen. Genau, ein Kontextwechsel. ;-)

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Oder der Blick in den Rückspiegel im Auto: Das ist ein solcher Automatismus - ich weiß doch, dass das Bild seitenverkehrt ist, also lese ich Schriftzüge auch schon von rechts nach links, ohne dass es mir überhaupt bewusst wird. Und wenn dann ein Feuerwehr- oder Rettungswagen hinter mir ist, dessen Front gleich in Spiegelschrift bemalt ist, dann passt's wieder nicht.

Noch viel dümmer: Werbung in Spiegelschrift auf Firmenwagen.

Nein, ich schau nicht in den Rückspiegel, um euren Schriftzug zu lesen, wenn ihr hinter mir fahrt.

Und wenn ihr am Straßenrand parkt, kann ich euren Schriftzug nicht lesen. Euer Pech.

LLAP 🖖

[encoder]

value="$aus_der_datenbank"

Klugschiss von mir: eigentlich sollte die Datenbank das Passwort nicht im Klartext speichern und somit auch keins eintragen können :-)

Welchen Zweck erfüllt es das dem Server bekannte Passwort einzutragen? Der Nutzer soll entweder ein eigenes eintragen, dann darf er aber nicht einfach auf Anmelden klicken können (*). Oder er wird automatisch angemeldet durch Cookies oder ähnliches, dann brauchst du aber das Klartextpasswort nicht an den Browser übertragen.

(*) Diese Funktion kann der Browser übernehmen, wenn er sich das Passwort merken soll. Aber dann trägt er das selber ein.

[dedlfix]

Tach!

value="$aus_der_datenbank" Klugschiss von mir: eigentlich sollte die Datenbank das Passwort nicht im Klartext speichern und somit auch keins eintragen können :-)

Nicht immmer ist eine reflexartige Antwort richtig. Es gibt auch Anwendungsfälle, da muss ein Passwort im Klartext oder zumindest wieder auslesbar gespeichert werden. Beispiel sei ein Passwort-Merkprogramm. Das soll sie nicht nur schlucken, sondern auch wieder rausrücken. In den Browsern ist eine solche Funktionalität auch eingebaut - zum automatischen Ausfüllen von Loginformularen.

Welchen Zweck erfüllt es das dem Server bekannte Passwort einzutragen?

Genau das ist die Frage, die zuerst beantwortet werden muss, bevor man irgendwelche Bewertungen von Do's und Don'ts vornehmen kann.

dedlfix.

[1211chef]

Nicht immmer ist eine reflexartige Antwort richtig. Es gibt auch Anwendungsfälle, da muss ein Passwort im Klartext oder zumindest wieder auslesbar gespeichert werden ...

Yepp.

Leute ...

Wo steht dass ich Passwörter ansonsten als Klartext speichere? Wenn ich hier im Forum eine Frage einstelle, lass ich doch besser das ganze Hintergrundgedönse weg und konzentriere mich auf den Kern der Sache. Es ist schön dass mir hier viele ihre Tipps geben, immer wieder ist was neues dabei bzw. es regt zum Nachdenken an. In der Regel hab ich aber meine Gründe, wieso ich etwas SO mache und nicht anders. Je ausladender ich mich erkläre, desto unklarer wird doch der Kern der Frage.

Und es führen immer mehrere Lösungswege nach Rom. Man könnte auch fragen: Wieso machst du das eigentlich so? ... wenn man´s unbedingt wissen will.

Ich hab jetzt gehört dass htmlspecialchars sonderzeichen übersetzt. Die frage ist, was mir das bei einem Passwort-Änderungsfeld eigentlich nützt. Ich lasse per perl.script sowieso nur bestimmte zeichen zu bzw. erwarte eine bestimmte Mischung von Zeichen. Und ich schreib eh kein PHP :=(

Mir ist schon klar dass man idr. Passwörter nur setzt und nicht in ein Formular einliest. Im Grunde ist es für dieses Projekt aber piepsegal ob ich nun ein Klartextfeld oder ein Passworteingabefeld benutze, oder ob ich das Passwort als Klartext oder verschlüsselt speichere denn für die Infos die in dieser DB stehen würde man eher was bezahlen damit man sie nicht bekommt :-)

Mir ist nur aufgefallen, dass chrome das einlesen nicht gestattet, es aber andere Browser zulassen und ich wollte wissen ob jemand was darüber weiss. Mehr eigentlich nicht.

Ich beantworte mir diese Frage also selbst: Die gurgeljungs haben sich gesagt dass niemand ein Passwort in ein Passwortfeld einzulesen hat, weil man das nicht TuT. Basta. Für mich ist´s ein Bug, denn gelegentlich braucht man´s eben doch - oder will es halt so.

So long, Gustl

[Der Martin]

Hallo,

Je ausladender ich mich erkläre, desto unklarer wird doch der Kern der Frage.

das hängt von deiner Begabung des Beschreibens und Erklärens ab. Aber unabhängig von dieser Begabung ist zusätzliche Hintergrundinfo meistens von Vorteil, weil erfahrene Helfer dann auch den Kontext sehen und den Fragesteller darauf hinweisen können, dass sein Ansatz für diesen Fall ungünstig oder ungeeignet ist, weil ...

Ich hab jetzt gehört dass htmlspecialchars sonderzeichen übersetzt.

Ja, und zwar die HTML-Sonderzeichen (öffnende und schließende spitze Klammern '<' und '>' sowie das Und-Zeichen '&') durch ihre entsprechenden Entity-Referenzen &lt;, &gt; und &amp;.

Die frage ist, was mir das bei einem Passwort-Änderungsfeld eigentlich nützt.

Soweit ich erkennen kann - nichts. Wie würdest du htmlspecialchars() da einsetzen wollen?

Und ich schreib eh kein PHP :=(

Okay. Aber Kontextwechsel müssen unabhängig von der verwendeten Sprache erkannt und richtig behandelt werden. Vermutlich hat Perl da ähnliche Funktionen; wenn nicht, musst du sie zu Fuß nachbauen.

Mir ist schon klar dass man idr. Passwörter nur setzt und nicht in ein Formular einliest. Im Grunde ist es für dieses Projekt aber piepsegal ob ich nun ein Klartextfeld oder ein Passworteingabefeld benutze, oder ob ich das Passwort als Klartext oder verschlüsselt speichere denn für die Infos die in dieser DB stehen würde man eher was bezahlen damit man sie nicht bekommt :-)

Du machst mir Angst.

Die gurgeljungs haben sich gesagt dass niemand ein Passwort in ein Passwortfeld einzulesen hat, weil man das nicht TuT. Basta. Für mich ist´s ein Bug, denn gelegentlich braucht man´s eben doch - oder will es halt so.

Kann sein. Dann muss man wohl einen anderen Browser verwenden.

Ciao,
 Martin

[1211chef]

hi martin,

erfrisched trocken wie immer, deine kommentare :-)

Ich hab jetzt gehört dass htmlspecialchars sonderzeichen übersetzt.

ich verbessere: im zuge des threads habe ich von @gunnar gehört ... (siehe weiter oben):

Das ist fehlerhaftes HTML und/oder fehlerhaftes PHP. htmlspecialchars() fehlt.

und ich fragte mich wieso das in verbindung mit input type password fehlerhaftes HTML sein soll - und ausserdem behandle ich im script formulareingaben eh "zu fuß" per regexp, wie du das so schön formulierst. wenn ich angenommen zulassen würde (was ich nicht mache) dass jemand im passwort <> und & verwenden darf, will ich doch erst recht nicht dass das übersetzt wird.

ich bin wirklich kein guter "erklärer". ich versuche mich zu bessern.

Du machst mir Angst.

berechtigt :-)

Kann sein. Dann muss man wohl einen anderen Browser verwenden.

sag das mal einem anwender

oiso dann, basd scho :-)

gustl

[Der Martin]

Hi,

erfrisched trocken wie immer, deine kommentare :-)

hmm, wenn du meinst - ist mir aber weder bewusst, noch meine konkrete Absicht.

echo "<input type=\"password\" name=\"pw\" value=\"$aus_der_datenbank\">";

Das ist fehlerhaftes HTML und/oder fehlerhaftes PHP. htmlspecialchars() fehlt.

Ich habe das, was du nicht mehr zitiert hast, mal zu syntaktisch korrektem PHP ergänzt: Die Backslashes zur Maskierung der Anführungszeichen haben gefehlt. Den Einsatz von htmlspecialchars() habe ich aber noch nicht ergänzt.

und ich fragte mich wieso das in verbindung mit input type password fehlerhaftes HTML sein soll - und ausserdem behandle ich im script formulareingaben eh "zu fuß" per regexp, wie du das so schön formulierst.

Es geht nicht um die Behandlung der Formulareingaben, sondern um die Behandlung der HTML-Ausgaben, hier die Vorbelegung des Eingabefelds. Was ist, wenn das Passwort ein Anführungszeichen enthält? Dann bekommst du tatsächlich fehlerhaftes HTML. Und da man normalerweise möglichst jedes Zeichen in einem Passwort zulassen möchte (auch Anführungszeichen), muss man den Wert, den man da in HTML einschleust, entsprechend behandeln. Der übliche Weg in PHP ist an der Stelle über htmlspecialchars():

echo "<input type=\"password\" name=\"pw\" value=\"", htmlspecialchars($aus_der_datenbank), "\">";

Da man nun nicht mehr einen einzigen Ausdruck als Parameter von echo hat, sondern drei getrennte, kann man auch die konstanten Teile in einfache anstatt doppelte Anführungszeichen setzen und erspart sich so das Gefummel mit dem Escaping der Anführungszeichen:

echo '<input type="password" name="pw" value="', htmlspecialchars($aus_der_datenbank), '">';

wenn ich angenommen zulassen würde (was ich nicht mache) dass jemand im passwort <> und & verwenden darf, will ich doch erst recht nicht dass das übersetzt wird.

Warum willst du das nicht zulassen?
Und doch, genau dann möchte man, dass diese Zeichen ersetzt werden, damit sie vom Browser wieder korrekt interpretiert werden können - nämlich als Teil des Attributwerts, nicht als Sonderzeichen. Vor allem aber auch das Anführungszeichen, das ich in meinem erssten Post vergaß zu erwähnen. Das übersetzt htmlspecialchars() auch in &quot;.

Kann sein. Dann muss man wohl einen anderen Browser verwenden.

sag das mal einem anwender

Sollte normalerweise kein Problem sein: Wenn ein Anwender erkennt (bzw. wenn man ihm klarmacht), dass der bisher verwendete Browser ein bestimmtes gewünschtes Feature nicht bietet, wird er freiwillig umsteigen, wenn ihm das wichtig genug ist.

Ciao,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Und da man normalerweise möglichst jedes Zeichen in einem Passwort zulassen möchte

Da ist ein „möglichst“ zu viel.

echo '<input type="password" name="pw" value="', htmlspecialchars($aus_der_datenbank), '">';

Und wenn man’s richtig™ macht sowieso, weil man sich schon Anführungszeichen spart:

<input type="password" name="pw" value="<?php echo htmlspecialchars($aus_der_datenbank); ?>">

oder kurz

<input type="password" name="pw" value="<?= htmlspecialchars($aus_der_datenbank) ?>">

LLAP 🖖

PS: Für kaputte Syntaxhighlighter kann ich nichts.

[dedlfix]

Tach!

echo '<input type="password" name="pw" value="', htmlspecialchars($aus_der_datenbank), '">';

Und wenn man’s richtig™ macht sowieso, weil man sich schon Anführungszeichen spart:

Tja, der OP ja kein PHP. Der Hinweis ist nur für PHP-Anwender gut, die zufällig auf diesen Thread stoßen. Bei Perl muss man das dann doch so ähnlich wie von Der Martin vorgeschlagen machen. Embedded Perl, so las ich, ist nicht üblich.

dedlfix.

[dedlfix]

Tach!

Ich hab jetzt gehört dass htmlspecialchars sonderzeichen übersetzt.

Ja, und zwar die HTML-Sonderzeichen (öffnende und schließende spitze Klammern '<' und '>' sowie das Und-Zeichen '&') durch ihre entsprechenden Entity-Referenzen &lt;, &gt; und &amp;.

Du hast das " übersehen.

Die frage ist, was mir das bei einem Passwort-Änderungsfeld eigentlich nützt.

Soweit ich erkennen kann - nichts. Wie würdest du htmlspecialchars() da einsetzen wollen?

Wenn das Passwort ein " enthält, das nicht zum Beispiel als &quot; notiert ist, dann ist an der Stelle das Attribut value zu Ende.

Mir ist schon klar dass man idr. Passwörter nur setzt und nicht in ein Formular einliest. Im Grunde ist es für dieses Projekt aber piepsegal ob ich nun ein Klartextfeld oder ein Passworteingabefeld benutze, oder ob ich das Passwort als Klartext oder verschlüsselt speichere

Dann nimm doch input type=text, wenn es unwichtig ist. type=password schützt ja dann nur gegen Über-die-Schulter-Blicke.

dedlfix.

[Der Martin]

Hallo,

Ja, und zwar die HTML-Sonderzeichen (öffnende und schließende spitze Klammern '<' und '>' sowie das Und-Zeichen '&') durch ihre entsprechenden Entity-Referenzen &lt;, &gt; und &amp;.

Du hast das " übersehen.

stimmt, hab ich mittlerweile auch schon gemerkt.

Die frage ist, was mir das bei einem Passwort-Änderungsfeld eigentlich nützt.

Soweit ich erkennen kann - nichts. Wie würdest du htmlspecialchars() da einsetzen wollen?

Wenn das Passwort ein " enthält, das nicht zum Beispiel als &quot; notiert ist, dann ist an der Stelle das Attribut value zu Ende.

Richtig. Ich halte es aber nicht für vernünftig, einem Passwort-Feld überhaupt eine Vorbelegung mit auf den Weg zu geben.

So long,
 Martin

[1211chef]

Tach!

Och Tach,

Dann nimm doch input type=text, wenn es unwichtig ist. type=password schützt ja dann nur gegen Über-die-Schulter-Blicke.

dedlfix.

Schon klar. Nene, ich nehm schon type password, schaut klüger aus :-) Ich lese das Passwort nicht ein, wieso auch.

Ich hab das PW (herrjemine) wirklich nur mal zum testen eingelesen und dabei eben festgestellt dass Browser darauf unterschiedlich reagieren, wofür ich keine Erklärung hatte. Was daraus für eine haarkleine Diskussion entsteht ist schon bemerkenswert.

Aber aus jedem Thread kann man sich was mitnehmen.

Schönen FeUerAbenT, Gustl

[Gunnar Bittersmann]

@@1211chef

Ich lasse per perl.script sowieso nur bestimmte zeichen zu

UX-Fehler.

“‘Your password contains invalid characters.’ No, your startup contains incompetent engineers.”
gefunden bei diamond rio pmp

bzw. erwarte eine bestimmte Mischung von Zeichen.

UX-Fehler.

“Your password must include at least an uppercase letter, a lowercase letter, a symbol, a number, two emoji, and the illusion of security.”
—Eric Meyer

“Your password constraints are killing me, @paypal. 1 symbol and no space? Don’t put that ‘hard to guess, easy to remember’ bullshit on me.”
—Kitty Giraudel

Und ich schreib eh kein PHP :=(

Das war geraten. Aus deinem ersten Posting ging nicht hervor, was das überhaupt für Code sein soll.

LLAP 🖖

[Google weiß alles]

<input type="password" name=\"pw\" value="$aus_der_datenbank">

Ich helfe niemanden dabei, Passwörter im Klartext zu speichern.