Перейти к содержимому
BXWiki

Не работает восстановление пароля - причины по убыванию частоты

Покупатель просит смену пароля, а письмо не приходит или форма молчит без сообщений. Разбираем причины по убыванию частоты.

Как проверить

Ищем запись в очереди писем:

SELECT ID, EVENT_NAME, DATE_INSERT, SUCCESS_EXEC FROM b_event
WHERE EVENT_NAME = 'USER_PASS_REQUEST' ORDER BY ID DESC LIMIT 5;
-- записи нет: письмо даже не сформировалось, и почта тут ни при чём
-- запись есть, а признак отправки пустой: очередь стоит, виноват агент

Очередь делит задачу пополам за один запрос. Отсутствие записи означает, что платформа до отправки не дошла, а необработанная запись - что дело в почте или в задании по расписанию.

Смотрим, что вернула сама форма:

global $APPLICATION;
print_r($APPLICATION->arAuthResult);   // сюда системные формы кладут ошибки и сообщения
// шаблон, который его не выводит, молча теряет и ошибку, и подтверждение
// системным формам нужны свои константы страницы: без них они не отрабатывают

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

Проверяем шаблон почтового события:

$rs = \Bitrix\Main\Mail\Internal\EventMessageTable::getList([
    'filter' => ['=EVENT_NAME' => 'USER_PASS_REQUEST'],
    'select' => ['ID', 'LID', 'ACTIVE', 'EMAIL_TO'],
])->fetchAll();
print_r($rs);   // шаблон должен быть активен и заведён для нужного сайта
// после крупных обновлений шаблон иногда остаётся выключенным

Проверяем учётные записи с этим адресом:

$users = \Bitrix\Main\UserTable::getList([
    'filter' => ['=EMAIL' => $email],
    'select' => ['ID', 'LOGIN', 'ACTIVE', 'EMAIL'],
])->fetchAll();
// несколько записей с одним адресом - источник самого странного поведения
// проверяют и активность: неактивной записи письмо не уйдёт вовсе

Одинаковый адрес у нескольких учётных записей платформа допускает. Восстановление при этом ведёт себя непредсказуемо для человека: письмо приходит не на ту запись, под которой он привык заходить.

Причины

  1. Письма с сайта не уходят вообще примерно 30% случаев

    ПризнакНе приходят и остальные письма: регистрация, заказы, уведомления.

    ПроверкаСмотрим очередь писем целиком и отправляем тестовое письмо со страницы проверки.

    Что делатьРазбираем отправку почты отдельно: настройки сервиса, записи домена, задание по расписанию.

  2. Шаблон события выключен или не заведён примерно 25% случаев

    ПризнакОстальные письма приходят, а именно это - нет; в очереди записи тоже нет.

    ПроверкаПроверяем список шаблонов события смены пароля: активность и привязку к сайту.

    Что делатьВключаем шаблон либо заводим его для нужного сайта; после обновлений он иногда остаётся неактивным.

  3. Шаблон формы не выводит сообщений примерно 20% случаев

    ПризнакСтраница просто перезагружается: ни ошибки, ни подтверждения не видно.

    ПроверкаПечатаем результат работы формы прямо в шаблоне и смотрим, что в нём лежит.

    Что делатьВозвращаем вывод результата в шаблон; в тиражных решениях этот блок обычно удалён при переверстке.

  4. Учётная запись не найдена или адрес не уникален примерно 15% случаев

    ПризнакПисьмо приходит на другую запись либо не приходит вовсе при верном адресе.

    ПроверкаИщем все учётные записи с этим адресом и сверяем их активность и логины.

    Что делатьПриводим адреса к уникальным: лишние записи объединяют или деактивируют, а активную оставляют одну.

  5. Контрольная строка протухла или уже использована примерно 10% случаев

    ПризнакСсылка из письма открывается, но платформа сообщает о неверной строке.

    ПроверкаСмотрим время выдачи строки у пользователя и запрашиваем смену пароля заново.

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

Если ничего не помогло

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

Проверяем политику паролей у группы пользователя. Требования к длине и составу проверяются при смене, и человек, пытающийся поставить привычный пароль, получает отказ, который в тиражном шаблоне может не отображаться.

Смотрим на капчу и защиту формы. Проактивная защита и капча отбрасывают запрос до обработки, и внешне это выглядит как молчаливая перезагрузка страницы, а не как ошибка проверки.

Частые вопросы

Почему не приходит только письмо о смене пароля?

Значит, отправка писем в целом работает, а конкретное событие не сформировалось: шаблон выключен или заведён для другого сайта. Проверяют очередь писем: если записи о событии нет, разбирать почту бессмысленно.

Форма ничего не выводит: ни ошибки, ни подтверждения.

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

Сколько живёт ссылка из письма?

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

Можно ли менять пароль пользователя из кода?

Да, обновлением полей учётной записи; отдельный метод смены пароля в некоторых версиях ведёт себя неожиданно. При любом способе действуют требования политики паролей группы.

Что делать, если у нескольких пользователей один адрес?

Приводить адреса к уникальным: платформа допускает повторы, но восстановление пароля и рассылки после этого работают непредсказуемо. Лишние записи объединяют или деактивируют.

Смежное

Первоисточник