Есть ряд проектов, где посетитель не должен заморачиваться какими-то логинами и паролями. Обычно такие проекты есть интернет-магазины. Оформил под гостем заказ и "забыл". Как оформить под гостем заказ мы тут рассматривать не будем. А вот как быть с дальнейшим оповещением клиента о статусе заказа? Об этом под катом. (только я наверное кат ставлю, даже Рыжиков этого не делает, грешник)
[spoiler] Суть в том, что вставить в каждое письмо такую ссылку, уникальную, при клике на которую пользователь бы автоматически авторизовывался на ресурсе под своим логином. Замечу, что он даже может и не знать своего пароля.
Я назвал эту технологию "ссылки автовхода". Рассмотрим на примере оповещений в техподдержку. Только сразу скажу, данный пример подойдет только для уникальных e-mail'ов, эту технологию вы можете настроить в главном модуле. Если ваш проект уже достаточно взрослый и там много пользователей и встречаются дубли e-mail'ов, то данная технология будет работать некорректно и требует доработки напильником.
Теперь как это сделать.
1. Добавляем доп.свойство пользователям под названием "Хеш-код", тип "строка", код "UF_HASH_CODE". Остальное на ваше усмотрение. Я бы добавил "Не разрешать редактирование пользователем".
2. Добавляем обработчик на добавление пользователя.
Вот и все. Теперь каждый новый пользователь имеет свой уникальный код. Можете добавить соль и сам хеш сделать каким угодно. На дальнейшие шаги не влияет никак. Только тут минус. Если у вас уже есть пользователи, то им надо будет отдельно проставить хеши. Если мало, то вручную, если много, то пробежаться сркиптом.
3. Редактируем почтовые шаблоны. Я покажу на примере "TICKET_CHANGE_BY_SUPPORT_FOR_AUTHOR" Вот что я добавил в футере письма:
<p>
Для просмотра и редактирования обращения воспользуйтесь <a href="http://#SERVER_NAME#/personal/support/?ID=#ID#&authologin=#AUTHOLOGIN_HASH#">этой ссылкой</a>.<br />
Мы просим Вас не забыть <a href="http://#SERVER_NAME#/personal/support/?ID=#ID#&authologin=#AUTHOLOGIN_HASH#">оценить ответы</a> службы техподдержки после закрытия обращения.<br />
<font color="Red">Внимание!</font> Не передавайте данные ссылки посторонним лицам, переход по ним приведет к авторизации под вашим логином.
</p>
Тип html. Вот что получилось в итоге:
Собственно я к каждой ссылки, по которой требуется авторизация приплюсовал authologin=#AUTHOLOGIN_HASH#.
4. Добавляем еще один обработчик, который бы наполнял эти маркеры перед отправкой письма.
Тут подход индивидуальный. Смотрим нужный тип и наполняем ссылки. Лучше обратиться к специалисту. Вообще, вся данная статья скорее для опытных разработчиков, чем для конечных администраторов.
5. Ну собственно все. Пользователю ушло письмо с уникальным кодом. Он может уже не заморачиваться о логинах и паролях. Только нам осталось авторизовать приходящих по таким ссылкам.
AddEventHandler("main", "OnBeforeProlog", "OnBeforePrologHandler");
function OnBeforePrologHandler()
{
global $APPLICATION, $_GET;
if ($_GET["authologin"] != "")
{
$rsUser = CUser::GetList($by="id", $order="asc", array("UF_HASH_CODE" => $_GET["authologin"]));
if ($arUser = $rsUser->GetNext())
{
CUser::Authorize($arUser["ID"]);
LocalRedirect($APPLICATION->GetCurPageParam("", array("authologin")));
}
}
}
Вот и все. И пусть пользователь хоть несколько раз делает заказ под гостем или пишет обращение в ТП под гостем. Все эти объекты будут суммироваться его e-mail'ом, на который он будет получать уникальные для себя ссылки автовхода.
Теперь по поводу безопасности. Да, если уникальная ссылка попадет в руки злоумышленника, то он сможет авторизоваться на ресурсе. Но ссылка приходит только на e-mail пользователя. Если хакер получил к нему доступ, то он и так авторизуется на ресурсе, если захочет.
В данном примере рассмотрено взаимодействие клиента и ТП. Если кому-то интересно, могу рассказать как сделать компоненту "Задать вопрос", которая будет принимать сообщения даже от неавторизованного пользователя и слать их в ТП. А клиент будет общаться с ТП посредством таких ссылок и полностью сохранит всю историю переписки.
Хотел плюсануть, но не нашел как. недавно сделал механизм очень похожий. но меняющий хэш после авторизации по ней. что бы по одной ссылке можно было авторизоватсья один раз. (необходимость=))
Прикольно, а если базу теперь взломают, то злоумышленнику достаточно иметь этот хеш, чтобы авторизоваться под любым пользователем, включая администратора.
Ведь пароль, к примеру, хранится намного сложнее... Или я что-то не правильно понял?
На самом деле все можно переписать на хеш от текущего мыла, который генерить на лету (с солью или без). Я у себя так и переписал, а тут что-то руки не дошли.
Ну и автовход можно сделать только для покупателей, с остальными никаких действий не производить.
Все эти сервисы вводятся через голову - что можно применять, что нет. Я лишь показал как это можно сделать.
И лично я бы рекомендовал базу админов любого серьезного проекта тщательно контролировать, а лучше прикрывать доступом только с доверенных IP-адресов, в идеале e-Token. Я пережил утечку прав админа гостям, я этого врагу не пожелаю
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».