c# - visual - windows forms zoom




Sollten Passwortfelder ihre Werte behalten, wenn ein Formular die Validierung nicht besteht? (4)

Ich habe ein typisches Anmeldeformular mit zwei Passwortfeldern.

<form>
    <%= Html.TextBox("Email", null) %>

    <%= Html.Password("password", null) %>
    <%= Html.Password("confirmPassword", null) %>

    <input type='submit' />
</form>

Wenn das Formular die Validierung nicht besteht und erneut angezeigt wird, behält das Textfeld seinen Wert bei, aber die Kennwortfelder sind immer leer.

Warum sollten die Passwortfelder ihre Werte nicht behalten? Und noch wichtiger, gibt es einen Grund, warum ich dieses Verhalten nicht außer Kraft setzen sollte?

Ich habe das Gefühl, dass dieses Verhalten die Benutzerfreundlichkeit einschränkt und dass Passwortfelder sich genauso verhalten würden wie Textfeldfelder - den eingegebenen Wert behalten, wenn Validierungsfehler vorliegen.

Ich benutze ASP.NET MVC, aber diese Frage bezieht sich mehr auf Benutzerfreundlichkeit und Sicherheit. Ich verstehe, dass das, was ich sehe, erwartetes Verhalten ist, und ein Blick auf die Methode Password(...) zeigt mir, dass es den Wert in ModelState explizit ignoriert.


Antwort von @ Scott Rippey, erklärt wirklich eine Menge. Sie können den Wert von @ Html.Password oder @ Html.PasswordFor nicht beibehalten, da er im Helper selbst fest codiert ist. Weitere Informationen finden Sie unter diesem Link. Behalte Passwortwert.

Lösung: Was Sie tun können, ist das Ersetzen der Passwort oder PasswordFor Box mit,

@Html.TextBoxFor(x => x.Password, new { type = "password" })

Die Antworten von @NickHeidke und @Chris Lively waren großartig und haben mich zu einigen Schlussfolgerungen geführt, die ich gerne teilen würde.

Vor allem in Bezug auf die Benutzerfreundlichkeit: Der EINZIGE Ort, an dem es für ein Kennwortfeld angemessen sein könnte, seinen Wert beizubehalten, ist ein "Anmeldungsformular", wenn das Formular die Validierung nicht besteht und das Validierungsproblem NICHT mit dem Passwort oder Passwort bestätigen. Es ist definitiv nicht geeignet für ein "Login" -Formular, "Passwort ändern" -Formular oder wahrscheinlich irgendeinen anderen Ort. Daher macht die Tatsache, dass Html.Password den ModelState ignoriert, ModelState Sinn.

Zweitens, was die Sicherheit betrifft: Wenn nicht sorgfältig implementiert, wird ein "Anmeldeformular" im Navigationsverlauf Ihres Browsers gespeichert. Wenn Sie "Zurück" drücken, wird Ihr Passwort erneut gesendet, was wahrscheinlich die Gültigkeitsprüfung nicht bestanden hätte, und das Formular mit Ihrem ausgefüllten Passwort zurücksenden. Die Tatsache, dass das Passwort ausgefüllt wird, ist KEINE Sicherheitsverletzung, weil es dasselbe Passwort ist, das der Browser bereits gespeichert und gesendet hat. Sie können "Quelle anzeigen" anzeigen, um das Kennwort anzuzeigen, aber Sie können auch die Seitenanforderung anzeigen, um das Kennwort zu sehen (z. B. mit FireBug).

Zugegeben, es ist einfacher und offensichtlicher, "View Source" zu sehen, wenn Sie ein ausgefülltes Passwort sehen, aber ich würde sagen, die bessere Lösung ist, das "Anmeldeformular" so zu implementieren, dass es nicht im Browserverlauf gespeichert wird. zum Beispiel das PRG Pattern mit einer Validierungs-Workaround , aber das ist ein ganz anderes Thema!

Meine Schlussfolgerung lautet : Passwort-Felder sollten fast immer klar sein, wenn sie angezeigt werden. Wenn Sie die Benutzerfreundlichkeit verbessern möchten und die Benutzer ihre Kennwörter nicht erneut eingeben möchten, sollten Sie zuerst die clientseitige Validierung verwenden . Und schließlich, wenn Sie wirklich wissen, was Sie tun, und wirklich Benutzerfreundlichkeit erhöhen möchten, ist es in Ordnung, die Werte auf einem Anmeldeformular beizubehalten. Aber es ist wahrscheinlich nicht die beste Idee.


Obwohl ich zustimme, dass dieses Verhalten bei der Anmeldung sinnvoll ist, hat es den Eindruck, dass es eine extrem schlechte Benutzererfahrung bietet, wenn man beispielsweise ein Benutzerkonto erstellt. Wenn es viele Felder in einem Formular gibt und der Benutzer einen Fehler in einem oder mehreren Feldern macht, ist das erneute Eingeben der Kennwörter (neu und bestätigen) sehr ärgerlich und wenn die Kennwortfelder in der Ansicht nicht sichtbar sind, ohne sie zu scrollen Es ist sehr leicht zu vergessen, sie erneut einzugeben.


Sie können den Wert in einem regulären Eingabefeld = Kennwortfeld zurücksenden.

Wenn Sie jedoch das .NET-Eingabesteuerelement verwenden, wird der Inhalt des Werts gelöscht, bevor das HTML an den Client gesendet wird.

Der Grund ist einfach: Sie wollten begrenzen, wie oft ein Passwort zwischen dem Server und dem Browser hin- und hergeschickt wurde. Dies hilft, die Exposition gegenüber bestimmten Systemen zu begrenzen. ( link )

Nun, offensichtlich, wenn Sie ssl verwenden, dann ist dies nicht viel eine Überlegung. Leider verwendet die große Mehrheit der Sites da draußen noch nicht SSL und wird fröhlich Daten hin und her im Klartext senden. Je öfter sich das Feld zwischen Client und Server bewegt, desto mehr Möglichkeiten hat jemand, es als FireSheep zu nutzen.

Denken Sie daran, dies bedeutet nicht, dass jemand, der die gesamte Konversation mit angehört, es vom ersten Post an nicht bekommen wird. Betrachten Sie es jedoch als eine einfache Option, um die Angriffsfläche zu begrenzen (nicht zu eliminieren).

Der nächste Grund ist, dass fast jedes Mal, wenn Websites das Kennwortfeld für den Benutzer nach einer Übermittlung anzeigen, dies darauf zurückzuführen ist, dass die Validierung nicht bestanden wurde. Dies könnte bedeuten, dass der Benutzername und / oder das Passwort falsch ist. Wenn man bedenkt, dass Passwortfelder nur Sternchen oder Punkte für den Benutzer anzeigen, gibt es keinen wirklichen Grund, es ihnen zurückzugeben.

Vorausgesetzt, dass Sie dem Benutzer niemals mitteilen möchten, welche der Anmeldeinformationen fehlgeschlagen ist (dh Sie wollen NICHT "Passwort ungültig" oder "Benutzername ungültig" sagen) UND dass normale Benutzer keine Möglichkeit haben, herauszufinden, ob sie ihre Eingabe fett gemacht haben, es ist viel besser IMHO, BEIDE zu löschen.

Abgesehen davon haben Sie hier die Wahl. Der Standard ist es zu leeren. Wenn man bedenkt, dass die große Mehrheit der Websites so arbeitet, wollen Sie wirklich gegen den Strich gehen? Persönlich finde ich, dass es viel besser ist, sich an UI-Standards zu halten, auch wenn wir ihnen nicht zustimmen.

Benutzer haben bereits genug Zeit mit all den verschiedenen verfügbaren Optionen.





validation