Покупательница написала в магазин мультибрендовой женской одежды: по ссылке из письма пароль не меняется, сайт пишет "неверное контрольное слово", войти и оплатить заказ не получается. Заказ при этом оформлен и ждёт оплаты.
В магазине подумали на капчу. Капчи на форме смены пароля нет. Причина нашлась в списке пользователей: на e-mail покупательницы было заведено четыре учётки.
Откуда берутся двойные учётки
Магазин работает на 1С-Битрикс с готовым решением и разрешает покупать без входа. Человек заполняет форму заказа, сайт сам заводит ему учётку и присылает письмо со ссылкой для пароля. Регистрироваться заранее не нужно, до заказа на один шаг меньше.
Когда тот же человек приходит за второй покупкой и снова не входит в кабинет, сайт мог бы узнать его по e-mail. Он не узнаёт и заводит ещё одну учётку. Так получается, когда сходятся три обстоятельства. Каждое по отдельности выглядит безобидно.
- 01Логин гостю сайт придумывает сам - берёт часть e-mail до знака @ - и проверяет, не занят ли он. Не занят: у прежней учётки логином записан адрес целиком.
- 02Готовое решение после этой проверки подставляет в логин e-mail. У него включена настройка "логин = e-mail". Совпал ли новый логин с уже существующим, сайт на этом шаге не проверяет.
- 03Проверка e-mail на уникальность в Битриксе по умолчанию выключена. Второй пользователь с тем же адресом сохраняется без ошибок.
В итоге каждый заказ без входа добавляет учётку с тем же логином и тем же e-mail. У покупательницы из письма их набралось четыре.
Почему с дублями не меняется пароль
После заказа сайт отправляет письмо со ссылкой для пароля. В ссылку зашит код - то самое контрольное слово. Он выдан для новой учётки, которую сайт только что завёл.
Форма смены пароля ищет учётку по логину. Логин у всех четырёх одинаковый, и Битрикс берёт первую попавшуюся - старую. Код из письма к ней не подходит, сайт отвечает "неверное контрольное слово". Вход по паролю ломается так же: сайт сверяет пароль со старой учёткой, а заказ лежит в новой.
SELECT LOWER(EMAIL), COUNT(*)
FROM b_user
WHERE ACTIVE = 'Y' AND LENGTH(EMAIL) > 0
GROUP BY 1
HAVING COUNT(*) > 1;Как исправили
Исправление - одна настройка главного модуля Битрикса: "Проверять E-mail на уникальность при регистрации" на вкладке "Авторизация". С ней зарегистрироваться второй раз на занятый адрес нельзя, а повторный покупатель без входа попадает со своим заказом в прежнюю учётку.
Перед тем как включать её у себя, проверьте три вещи.
- →Параметр оформления заказа. Заказ гостя ложится в существующую учётку, только если это разрешено в параметрах компонента оформления заказа (в коде параметр называется ALLOW_APPEND_ORDER). В нашем случае он был включён. Если выключен, сайт не сможет ни завести вторую учётку, ни положить заказ в первую, и повторный покупатель без входа заказ не оформит.
- →Накопившиеся дубли. Настройка действует на новые заказы, старые учётки остаются. Лишние мы отключили и убрали с них e-mail покупателя, чтобы адрес остался за одной рабочей учёткой. На троих покупателей таких учёток набралось пять.
- →Логин и обмен с 1С. У учёток с живыми заказами логин не меняли. Он входит в код покупателя, с которым заказ выгружается в 1С: сменится логин - сменится и код.
Что проверили после
| Что проверяли | Результат |
|---|---|
| Регистрация с новым e-mail | Проходит |
| Регистрация с e-mail, который уже есть на сайте | Не проходит, в том числе при другом регистре букв |
| Повторный покупатель без входа | Заказ привязывается к его прежней учётке |
| Покупатель меняет данные в своём профиле | Сохраняются без ошибок |
Живой заказ для этого не оформляли: вызывали ту же проверку, которую сайт выполняет при регистрации.
Сколько покупателей это задело
К моменту жалобы магазин продавал две недели. Дубли успели появиться у троих покупателей из семи десятков учёток на сайте. Ни один из троих не мог восстановить пароль, одна не могла оплатить заказ.
Ловушка срабатывает только на второй покупке без входа. Первый заказ проходит гладко, поэтому на запуске и на тестовых заказах её не видно. Проявляется она на тех, кто вернулся в магазин ещё раз.
Разбор причины, настройка, чистка учёток и проверка уложились в один день.
Готовое решение экономит месяцы на старте, но часть его настроек по умолчанию проявляет себя только на живых покупателях. Из той же серии: правки карточки товара, которых не видно на телефоне, и виджет оплаты, который молча теряет рассрочку. Находить и закрывать такие места - часть сопровождения магазина. А свой магазин проверьте запросом выше: пустой ответ значит, что дублей нет.
