Контрольная строка для смены пароля что это
Смена пароля
Поле «Контрольная строка» имеется в форме для смены пароля. Однако, на эту форму имеет смысл переходить, только после того, как Вы отправили запрос на смену пароля, после чего Вам на email будет выслана контрольная строка.
| Цитата |
|---|
| Следуйте на форму для запроса пароля. После получения контрольной строки следуйте на форму для смены пароля. |
а какой компонент отвечает за смену пароля без поля «контрольная строка»?
есть ли что-либо в таком духе?
— старый пароль
— новый пароль
— подтверждение пароля
| Цитата |
|---|
| theo_ пишет: а какой компонент отвечает за смену пароля без поля «контрольная строка»? |
| Цитата |
|---|
| theo_ пишет: какой компонент отвечает за смену пароля без поля «контрольная строка»? |
Для авторизованных пользователей сделал.
Эх. А надо сделать еще и для тех, кто забыл свой пароль
Выводим форму forgotpasswd
Вводится логин или емэйл и на почту пользователю уходит нужное сообщение
Как сделать так, чтобы после его отправки пользователю вывелось сообщение о необходимости проверить свою почту?
Есть ли какое-либо событие? По типу onAfterUserLogin и т.п.
Курил маны по api, но не нашел информации по данной теме
Люди, помогите!
Чтобы изменить пароль в тех ситуациях, решение которых не найдено выше, можно воспользоваться следующим методом: http://dev.1c-bitrix.ru/api_help/main/reference/cuser/update.php
Смена пароля
Поле «Контрольная строка» имеется в форме для смены пароля. Однако, на эту форму имеет смысл переходить, только после того, как Вы отправили запрос на смену пароля, после чего Вам на email будет выслана контрольная строка.
| Цитата |
|---|
| Следуйте на форму для запроса пароля. После получения контрольной строки следуйте на форму для смены пароля. |
а какой компонент отвечает за смену пароля без поля «контрольная строка»?
есть ли что-либо в таком духе?
— старый пароль
— новый пароль
— подтверждение пароля
| Цитата |
|---|
| theo_ пишет: а какой компонент отвечает за смену пароля без поля «контрольная строка»? |
| Цитата |
|---|
| theo_ пишет: какой компонент отвечает за смену пароля без поля «контрольная строка»? |
Для авторизованных пользователей сделал.
Эх. А надо сделать еще и для тех, кто забыл свой пароль
Выводим форму forgotpasswd
Вводится логин или емэйл и на почту пользователю уходит нужное сообщение
Как сделать так, чтобы после его отправки пользователю вывелось сообщение о необходимости проверить свою почту?
Есть ли какое-либо событие? По типу onAfterUserLogin и т.п.
Курил маны по api, но не нашел информации по данной теме
Люди, помогите!
Чтобы изменить пароль в тех ситуациях, решение которых не найдено выше, можно воспользоваться следующим методом: http://dev.1c-bitrix.ru/api_help/main/reference/cuser/update.php
Если забыли пароль для входа на сайт uslugi.tatarstan.ru
Что делать, если забыли пароль для входа в личный кабинет портала Государственных и муниципальных услуг Татарстана? — Воспользоваться формой запроса.
Появится форма запроса контрольной строки для смены пароля.
Заполните снова строку номера вашего телефона и введите символы, изображённые на картинке.
Кликните на Запросить.
На ваш мобильный телефон будет выслана комбинация цифр (контрольная строка), которой необходимо воспользоваться быстрее, так как есть определённое время для её срока действия.
Внимание! Сейчас вы только сменили пароль, а не входите в личный кабинет.
Пароль успешно изменён. А вот только сейчас можно войти в личный кабинет с помощью нового пароля.
О настройках личного кабинета на портале Государственных и муниципальных услуг поговорим в следующий раз.
Форма авторизации
Компонент служит для вывода формы авторизации.
Описание system.auth.form
Используется обычно в шаблоне дизайна сайта. Компонент является стандартным и входит в дистрибутив модуля.
В визуальном редакторе компонент расположен по пути: Служебные > Пользователь > Форма авторизации.
Параметры
| Поле | Параметр | Описание |
| Дополнительно | ||
|---|---|---|
| Страница регистрации | REGISTER_URL | Указывается путь к странице регистрации пользователя. |
| Страница забытого пароля | FORGOT_PASSWORD_URL | Указывается путь к странице восстановления пароля. |
| Страница профиля | PROFILE_URL | Указывается путь к странице с параметрами пользователя. |
| Показывать ошибки | SHOW_ERRORS | [Y|N] При отмеченной опции будут отображаться ошибки, возникающие при авторизации в системе. |
Пример вызова
Механизм восстановления пароля
Если пользователь запросил восстановление пароля, то восстановление происходит по следующему механизму:
Пользовательские комментарии
Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.
Для этого нужно всего лишь авторизоваться на сайте
Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.
Также Пользовательские комментарии не являются местом для обсуждения функционала. По подобным вопросам обращайтесь на форумы.
Смена пароля: 10 шагов к хорошей реализации
В этой статье поделимся опытом компании True Engineering: как мы реализовали механизм смены пароля для личного кабинета интернет-портала. В процессе мы использовали и обобщили 10 best practices. Надеемся, что они пригодятся всем, кто решает ту же задачу или хочет проверить свой функционал.
У нашего клиента есть интернет-портал и пользователи, данные которых заведены в домене. Доступ в личный кабинет предоставляется по паролю.
Ранее, чтобы обновить пароль, пользователь оставлял заявку на портале, она летела к администратору, который вручную генерировал пароль и привязывал его к заявке. В результате пользователю приходило email-уведомление: «Ваш пароль изменён на такой».
Мы хотели изменить три момента:
Итак, стало понятно, что механику смены пароля пора изменить.
Кейсы такого типа требуют баланса между информативностью и умеренностью. Пользователя не стоит перегружать деталями и абзацами текста. В то же время написать два Input и поставить одну кнопку тоже неправильно. Поэтому мы привлекли к работе дизайнера и копирайтера. А по результату работы составили 10 подсказок на основе своего опыта, как сделать механику смены пароля оптимальной и на фронтенде, и на бэкенде.
1. Оформите письмо и страницу со сменой пароля по UI kit
Сделайте письмо и страницу со сменой пароля по UI kit, то есть красиво, в общем стиле сайта и хорошо локализованной. Это нужно, чтобы легче ориентироваться. Даже если человек отвлекся от процесса, то вернувшись через 10 минут, он поймёт, на каком ресурсе находится и зачем он тут.
2. Напишите понятные тексты
Поработайте над текстами, чтобы из них стало предельно понятно, что сейчас происходит и что требуется от пользователя. Желательно, чтобы тексты соответствовали редакционной политике заказчика (стиль общения) и были составлены с учётом best practices. Так получаются красивые и содержательные письма.
3. Укажите, кто и когда сбросил пароль
Для безопасности процесса добавьте в письмо информацию о том, когда запрошена ссылка для смены пароля и с какого устройства, с какой операционной системы и IP-адреса. Если пользователь не запрашивал ссылку или видит устройство, которое ему не принадлежит — это повод задуматься, а бить тревогу.
Эту информацию мы сделали посветлее, чтобы она была видна, но не мозолила глаза. А основная ссылка на смену пароля нарисована большой яркой кнопкой — пользователь её сразу видит.
4. Сделайте ссылку на смену пароля временной
Временная ссылка на смену пароля — это общемировая практика. После того, как пользователь подал заявку на смену пароля, ему нужно поменять этот пароль в определенное время: например, в течение 5 минут или 24 часов. Получается, что есть четко ограниченное временное окно, в которое кто угодно может поменять пароль пользователю. Поэтому в целях безопасности это время ограничено.
5. Не используйте сторонних библиотек на странице смены пароля
В нашем случае прежняя страница смены пароля имела общий master page со всем проектом, и уже на ней загружалась куча различных сторонних библиотек. Не повторяйте наших ошибок, сразу сделайте её безопасной. Новая страница, на которую ведёт ссылка и вбивается пароль, не использует никаких сторонних библиотек.
6. Исключите техподдержку из процесса (без крайней необходимости)
Пусть пользователь сам меняет пароль — это несложная операция и легко автоматизируемая. Она состоит из трёх этапов: запросил пароль, получил ссылку на замену, обновил пароль. Лишь в крайних случаях к процессу подключается отдел поддержки — и только в случае, если пользователь сам не смог поменять пароль.
Проблемными заявками занимаются специалисты, которые вникают в технические причины ошибок и способны самостоятельно их исправить.
7. Сделайте техподдержке красивый UI — им будет приятно
Упростите работу сотрудникам техподдержки, показывая заявки на смену пароля не в Sharepoint, а в красивом UI специальной системы заявок.
8. Пишите историю ошибок
Сотрудник техподдержки будет работать быстрее, если сразу увидит в заявке, что именно происходило, когда пользователь не смог сменить пароль, то есть всю историю ошибок, которые получал пользователь. Гораздо проще разбираться в причинах с учетом этой информации.
Например, пользователь не понимает, что такое спецсимволы, или не видит сообщения о том, что пароль должен содержать буквы верхнего регистра. У них масса способов найти эту заявку: по логину, по времени, когда он оставлял эту заявку и т.д.
9. Дайте техподдержке возможность сменить пароль
Дайте службе техподдержки возможность поменять пароль самостоятельно и сообщить его пользователю. Желательно, чтобы эта смена пароля тоже была сделана в безопасном режиме — страница поднимается в отдельном окне браузера и сделана без сторонних библиотек. После того, как пользователь подтвердит, что всё готово, она самостоятельно закроется.
10. Отслеживайте запросы и динамику
Мы настроили мониторинг при помощи Serilog. В ELK сбрасываем событие, а потом через Grafana отслеживаем четыре разновидности ситуации, когда пользователь запросил смену пароля:
a. Зеленая линия — пользователь был найден в домене,
b. Красная линия — логин пользователя не был найден в домене. Для нас второе действие — это маркер. Если этот график ползет вверх, то превышает одну попытку в сутки, это может означать, что какой-то недобросовестный товарищ пытается собрать базу.
На это мы можем оперативно отреагировать, отключив айпишник. Далее эту деятельность можно автоматизировать — например, автоматически отключать айпишник после десяти запросов. Но это не всегда работает, поскольку некоторые компании сидят в интернете с одного IP-адреса, поэтому пока просто мониторим этот график. Его постоянно просматривает служба поддержки. И если он вдруг пойдёт вверх, в моменте решим, что нам делать.
c. Зелёная линия — пользователь успешно запросил смену пароля и открыл нужную ссылку, соответственно, мы предполагаем, что всё хорошо.
d. Красная линия — пользователь не смог открыть страницу со сменой пароля. Ссылка была с несуществующим ID, устаревшая и т.д. Довольно странно предполагать, что какой-то хакер пытается перебрать уникальные идентификаторы, чтобы поймать тех, кто пытается сменить пароль. Но в принципе мы можем мониторить эти события — и если увидим, что этот график пошёл вверх, то можем разобрать события и посмотреть, что происходит. Например, может оказаться, что ID битый, от него отрезался кусок и ссылка в email вставляется некорректно.
В итоге у нас есть четыре графика и сплошное полотно событий, где можем понимать, что произошло. Все инструкции по настройке Grafana есть здесь.
Так мы добились своих целей: автоматизировали смену пароля, освободив рабочее время администратора для более важных задач, и сделали процесс максимально безопасным.