Должны ли поля Пароль сохранять свои значения, если форма не проходит проверку?

У меня есть типичная форма регистрации с двумя полями пароля.

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

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

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

Если форма не проходит проверку и повторно отображается, текстовое поле сохраняет свое значение, но поля пароля всегда пусты.

Почему поля пароля не сохраняются? И что еще более важно, есть ли какая-то причина, по которой я не должен переопределять это поведение?

Я чувствую, что такое поведение уменьшает удобство использования и предпочитает, чтобы поля пароля велись так же, как поля текстового поля, - сохраняя введенное значение при наличии ошибок проверки.

Я использую ASP.NET MVC, но этот вопрос больше касается удобства и безопасности. Я понимаю, что то, что я вижу, - это ожидаемое поведение, и просмотр метода Password(...) показывает мне, что он явно игнорирует значение в ModelState.

Ответ 1

Ответы, представленные @NickHeidke и @Chris Lively, были отличными и привели меня к нескольким выводам, которые я хотел бы поделиться.

Прежде всего, в отношении удобства использования: ТОЛЬКО место, где может быть поле для пароля, чтобы сохранить его значение, находится в форме "регистрации", когда форма не проходит проверку, а проблема проверки не является связанных с паролем или подтвердите пароль. Это определенно не подходит для формы "входа в систему", "сменить пароль" или, возможно, в любом другом месте. Поэтому тот факт, что Html.Password игнорирует ModelState, имеет прекрасный смысл.

Во-вторых, в отношении безопасности: если не будет тщательно реализовано, форма регистрации будет сохранена в истории навигации браузера. Нажатие "Назад" повторит отправку вашего пароля, что, вероятно, приведет к отказу в проверке и вернет форму с заполненным паролем. Тот факт, что пароль заполнен, НЕ является нарушением безопасности, поскольку, поскольку он имеет тот же пароль, который браузер уже сохранил и отправил. Вы можете "просмотреть источник", чтобы увидеть пароль, но вы также можете просмотреть запрос страницы, чтобы увидеть пароль (например, используя FireBug).

Конечно, легче и понятнее "View Source", когда вы видите заполненный пароль, но я бы сказал, что лучшее решение реализует форму "регистрации" способом, который не сохраняется в история браузера; например, PRG-шаблон с обходным решением валидации, но это совершенно другая тема!

Мое заключение - это: поля пароля всегда должны быть ясными, когда они показываются. Если вы хотите повысить удобство использования и не хотите, чтобы пользователи перепечатывали свои пароли, сначала используйте проверку на стороне клиента! И, наконец, если вы действительно знаете, что делаете, и действительно хотите повысить удобство использования, вполне можно сохранить значения в форме регистрации. Но это, вероятно, не самая лучшая идея.

Ответ 2

Вы можете отправить значение обратно в поле обычного ввода = пароль.

Однако, если вы используете элемент управления .net, тогда он очистит содержимое значения до отправки html обратно клиенту.

Причина проста: они хотели ограничить количество раз, когда пароль отправлялся туда и обратно между сервером и браузером. Это помогает ограничить воздействие некоторых систем. (ссылка)

Теперь, очевидно, если вы используете ssl, тогда это не очень важно. К сожалению, подавляющее большинство сайтов там STILL не используют SSL и будут счастливо отправлять данные в ящик. Чем больше раз, когда это поле перемещается между клиентом и сервером, тем больше возможностей у кого-то хватит на него FireSheep.

Помните, это не означает, что кто-то, кто прослушивает весь разговор, не получит его с первого поста. Однако рассмотрите это как простой вариант, чтобы ограничить (не исключать) поверхность атаки.

Следующая причина заключается в том, что почти каждый раз, когда сайты отображают поле пароля пользователю после отправки, это потому, что проверка не прошла. Это может означать неправильное имя пользователя и/или пароль. Учитывая, что поля пароля отображают только звездочки или точки для пользователя, нет никакой реальной причины вернуть их им.

Учитывая, что вы никогда не хотите сообщать пользователю, какой из учетных данных не удалось (например: вы НЕ хотите сказать "пароль недействителен" или "имя пользователя недействительно" ) И что обычные пользователи не имеют способа выяснить, их вход, он намного лучше ИМХО, чтобы очистить ОБА.

Все это в стороне, у вас есть выбор здесь. Стандартом является его очистка. Учитывая, что именно так работает огромное большинство сайтов, вы действительно хотите пойти против зерна? Лично я считаю, что нам намного лучше придерживаться стандартов пользовательского интерфейса, даже если мы не согласны с ними.

У пользователей уже достаточно сложное время со всеми различными доступными опциями.

Ответ 3

Объяснение, которое я слышал для этого в прошлом, заключается в том, что если пользователь нажимает кнопку "Отправить" и уходит со своего компьютера, кто-то еще не сможет прийти и повторно отправить без их ведома.

Ответ 4

Ответ, данный @Scott Rippey, действительно объясняет многое. Вы не можете сохранить значение @Html.Password или @Html.PasswordFor, потому что оно жестко запрограммировано в самом помощнике. для получения дополнительной ссылки на эту ссылку. сохранить значение пароля.

Решение: Что вы можете сделать, это заменить поле Password или PasswordFor,

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

Ответ 5

Хотя я согласен с тем, что при входе в это поведение разумно, он чувствует, что он обеспечивает чрезвычайно плохой пользовательский интерфейс, когда говорят, создавая учетную запись пользователя. Когда в форме есть много полей, и пользователь делает ошибку в одном или нескольких полях, необходимость повторного ввода паролей (новых и подтверждений) очень раздражает, а когда поля пароля не видны без прокрутки очень легко забыть повторно ввести их.