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

Question

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

---

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

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

Answer 2

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

Прежде всего, в отношении удобства использования: ЕДИНСТВЕННОЕ место, где для поля пароля может быть уместно сохранить свое значение, находится в форме «регистрации», когда форма не проходит проверку, а проблема проверки НЕ связанные с паролем или подтвердить пароль. Это определенно не подходит для формы «войти», «изменить пароль» или, возможно, любого другого места. Следовательно, тот факт, что Html.Password игнорирует ModelState, имеет смысл.

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

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

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

Answer 3

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

Answer 4

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

Решение: то, что вы можете сделать, это заменить поле Пароль или Пароль для на

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

Answer 5

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