如果密码字段保留其值，如果一个表单没有通过验证？ [英] Should Password fields retain their values if a form does not pass validation?

问题描述

我有一个典型的注册表单有两个密码字段。

I have a typical sign-up form with two password fields.

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

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

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

如果表单验证失败而重新显示，文本字段保留其值，但密码字段始终空白。

If the form fails validation and is redisplayed, the text field retains its value but the password fields are always blank.

为什么不应该密码的字段保留其值？并更重要的是，没有任何理由，我不应该覆盖此行为？

Why shouldn't the password fields retain their values? And more importantly, is there any reason I shouldn't override this behavior?

我觉得这种行为降低可用性，并且将preFER密码字段的运行方式相同文本字段 - 保持输入值时存在验证错误

I feel like this behavior decreases usability, and would prefer password fields to behave the same way as textbox fields -- keeping the entered value when validation errors exist.

我使用ASP.NET MVC，但这个问题涉及更多的可用性和安全性。据我所知，我所看到的是预期的行为，并采取一看密码（...）方法让我发现，它明确地忽略了<$ c中的价值$ C>的ModelState 。

I'm using ASP.NET MVC, but this question pertains more to usability and security. I understand that what I'm seeing is expected behavior, and taking a look at the Password(...) method shows me that it explicitly ignores the value in ModelState.

推荐答案

提交@NickHeidke的答案，@克里斯生动都是伟大的，导致我，我想和大家分享一些结论。

The answers submitted by @NickHeidke and @Chris Lively were both great and led me to a few conclusions that I would like to share.

首先，关于可用性：唯一的地方，一个密码字段保留其值是注册形式，当表单没有通过验证它可能是合适的，验证问题是不相关的密码或确认口令。这绝对是不恰当的登录的形式，更改密码的形式，或可能是任何其他地方。因此， Html.Password 忽略了一个事实的的ModelState 是非常合情合理的。

First of all, regarding usability: the ONLY place where it might be appropriate for a password field to retain its value is on a "sign-up" form, when the form does not pass validation, and the validation issue is NOT related to the password or confirm password. It is definitely not appropriate for a "log-in" form, "change password" form, or probably any other place. Therefore, the fact that Html.Password ignores the ModelState makes perfect sense.

二，关于安全：除非认真贯彻落实，是注册的形式将被保存在浏览器的导航历史记录。 pressing返回将重发您的密码，这可能会失败验证，并与您的密码填写交回表格。该密码填写的事实并不是一个安全漏洞，但因为其相同的密码，浏览器已保存和发送。你可以在查看源文件中看到密码，但你可以查看页面请求中看到密码太（例如，使用萤火虫）。

Second, regarding security: unless carefully implemented, a "sign-up" form will be saved in your browser's navigation history. Pressing "Back" will resend your password, which would probably fail validation, and return the form with your password filled out. The fact that the password is filled out is NOT a security breach though, because its the same password that the browser already saved and sent. You can "View Source" to see the password, but you could view the page request to see the password too (for example, using FireBug).

当然，它更容易和更明显的查看源文件，当你看到一个密码填写了，但我想说的更好的解决方案是在不保存的方式实施注册的形式浏览器历史记录;例如，在<一href=\"http://stackoverflow.com/questions/5538005/post-redirect-get-in-asp-net-mvc-and-validation-with-restful-urls\">PRG图案以验证的解决办法，但是这是一个完全不同的话题！

Granted, it is easier and more obvious to "View Source" when you see a password filled out, but I'd say the better solution is implementing the "sign-up" form in a way that isn't saved to browser history; for example, the PRG Pattern with a Validation workaround, but that is a whole different topic!

我的结论是：所示，当密码字段应该总是很清楚。
如果你想提高可用性，不想让用户重新输入密码，尽量使用客户端验证第一！
最后，如​​果你真的知道你在做什么，真正要提高可用性，它的确定坚持一个注册表单上的值。但它可能不是最好的主意。

My conclusion is this: password fields should almost always be clear when shown. If you want to increase usability and don't want to make users retype their passwords, try to use client-side validation first! And finally, if you really know what you're doing, and really want to increase usability, it's ok to persist the values on a sign-up form. But it probably isn't the best idea.

这篇关于如果密码字段保留其值，如果一个表单没有通过验证？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！