/wa-system/auth/waAuth.class.php
/**
* @param string $email
* @return array|null
*/
protected function getByEmail($email)
{
if (!$this->isValidEmail($email)) {
return null;
}
$model = new waContactModel();
$where = array();
if ($this->options['is_user']) {
$where[] = "c.is_user = 1";
}
$where[] = "c.password != ''";
$where[] = "e.email LIKE 'l:email'";
$where[] = "e.sort = 0";
$where = join(' AND ', $where);
$sql = "SELECT c.* FROM wa_contact c
JOIN wa_contact_emails e ON c.id = e.contact_id
WHERE {$where}
ORDER BY c.id LIMIT 1";
return $model->query($sql, array('email' => $email))->fetchAssoc();
}вот это не нужно:
$where[] = "c.password != ''";
потому, что, если у клиента настроен вход по одноразовым паролям на мыло, то у покупателей вполне могут быть пустые пароли.
вот это не нужно совсем:
$where[] = "e.sort = 0";
Если у человека 2 мыла, то почему бы нельзя логиниться по второму?
Прошу решить этот вопрос в дальнейших обновлениях т.к. я не нашел другого выхода, как внести правки в движок
19 комментариев
Опишите, пожалуйста, конкретную ситуацию, когда у пользователя возникает проблема, связанная с тем, что вы написали.
объеденились два контакта там почта @yandex.ru и @ya.ru
Войти по второй не получится. Это старый баг.
ну я вроде подробно расписал где собака зарыта.
человек импортировал юзеров из других двух своих сайтов на третий. потом объединил юзеров через crm. при этом у него в wa_contact_emails не пересортировались поля sort. некоторые начинаются с 1, некоторые с 2, а не с 0, как предполагает waAuth. Ну и пароли юзеров не заданы т.к. у него используется система одноразовых паролей на мыло.
При каком действии возникает ошибка?
Ошибки никакой нет. Просто юзер хочет зайти в лк, пытается авторизоваться, а ему в ответ: Пользователь не найден, пожалуйста зарегистрируйтесь. И снова начинают множиться дубли юзеров. Если учесть, что у клиента доступ в магазин строго для юзеров из определенной категории, то приходится постоянно этих юзеров отправлять в нужную категорию. Потом он запускает отлов дубликатов через crm, снова меняется sort на ненулевой и снова юзер не может зайти. Два дня искал что происходит и не мог понять. Юзер есть, ничем не отличается от других, а зайти не может.
Если бы при объединении контактов у объединённого контакта хотя бы для одного email-адреса всегда сохранялось значение sort=0, это решило бы проблему?
это не полное решение проблемы. так же нужно проверять способ авторизации, и, если авторизация по одноразовому паролю, то не требовать чтобы поле пароле было не пусто. ведь наличие пароля, при этом методе, не обязательно.
ну и, если подумать логически... если у меня два или три мыла в профиле, почему я должен логиниться только по первому мылу? я может и не помню уже какое было первым. так же это решение с sort=0 не решит проблему у тех юзеров, которые уже запороли свои таблицы слиянием без переиндексауии sort.
Чтобы войти по одноразовому паролю, нужно сначала зарегистрироваться по одноразовому паролю. И во время такой регистрации в поле wa_contact.password сохраняется хеш пароля. После этого при авторизации по одноразовому коду SQL-запрос правильно находит нужный контакт.
У вас выполняются такие же действия, но результат оказывается другим?
А вот и нет. Можно импортировать контакты из другого своего сайта штатными средствами вебасист. В этом случае пароли не переносятся. Но они не нужны при авторизации по одноразовому паролю.
Будет ли более полным решением проблемы также исправление значений sort в таблицах тех баз данных, где эти значения были испорчены ранее?
На крупных проектах есть вероятность, что такое метаобновление не отработает до конца. Тогда уж должна быть кнопочка для пересортировки.
А можно вопрос? Зачем это? Повторюсь. Почему нельзя логиниться с двух email адресов, если они оба вписаны у тебя в профиле?
Тогда уж было бы более логичным вписать основной e-mail и основной номер телефона в таблицу wa-contact, и использовать эти поля для логина. Вроде бы когда-то так и было с email и это было уникальным полем. А то какие-то танцы с бубнами получаются.
Имхо, раз уж лезть в wa-auth, то не стоит делать костыли к костылям, а продумать чтобы было раз и навсегда, и подходило ко всем вашим методам авторизации.
Например там же есть блок условий, который определяет что введено: емэйл, логин или телефон. Хотя в настройках движка уже определено что мы используем в качестве логина, а в поле для логина конкретно написано "Введите email". Зачем же тогда этот блок условий? Нужно делать поиск того, что в настройках, а не всего подряд.
Жалобы на текущее поведение авторизации от пользователей к нам пока не поступали, насколько я знаю. Если плохо смотрел, поправьте, пожалуйста.
Когда будут жалобы от конкретных пользователей, мы посмотрим, как можно разрешить проблемы в описанных ими случаях. Если жалоб нет, то оснований менять логику авторизации пока не видно, кроме разве что вашего недоумения.
Если вы уверены, что ваш вариант логики решит какие-то проблемы пользователей, предложите его в разделе идей и предложений, пожалуйста.
Через какое-то время все забудут про это, поступят жалобы, а вы их отфутболите потому что снова будет не понятно чего хотят эти несносные юзеры.
Хотя бы сам запрос посмотрите
у вас:
$where[] = "c.password != ''"; $where[] = "e.email LIKE 'l:email'"; $where[] = "e.sort = 0"; $where = join(' AND ', $where);$sql = "SELECT c.* FROM wa_contact c JOIN wa_contact_emails e ON c.id = e.contact_id WHERE {$where} ORDER BY c.id LIMIT 1";ну это ж вообще так не делается. как минимум должно быть так:
$where[] = "c.password != ''"; $where[] = "e.email LIKE 'l:email'"; $where = join(' AND ', $where); $sql = "SELECT c.* FROM wa_contact c JOIN wa_contact_emails e ON c.id = e.contact_id WHERE {$where} ORDER BY e.sort LIMIT 1";Хотя нет. Даже так нельзя. Это ничего не даст. Но не важно. Я к тому, что можно использовать средства mysql для сортировки полей, а не писать sort=0
Вообще нельзя так джоинить таблицы как у вас сделано. Поле контакта одно, а емэйлов у контакта может быть много. Если бы такое было бы в плагине, вы бы точно отказ в публикации сделали.
Правильно ли я понимаю, что, как минимум, есть проблема в логике объединения контактов, в результате которой у итогового контакта отсутствует email-адрес в таблице wa_contact_emails со значением sort=0?
У вас такие контакты появляются и сейчас в ходе объединения в последней версии CRM? Или они появились когда-то раньше и с помощью какой версии CRM они были объединены, вы уже точно не помните?
Честно говоря, я не понимаю зачем вообще нужна проверка на sort? даже если вы исправите логику объединения контактов, то это не починит сотни баз, где объединение уже было выполнено с ошибкой.
если так нужно оставить sort, то лучше искать минимум, а не =0