Есть ряд проектов, где посетитель не должен заморачиваться какими-то логинами и паролями. Обычно такие проекты есть интернет-магазины. Оформил под гостем заказ и "забыл". Как оформить под гостем заказ мы тут рассматривать не будем. А вот как быть с дальнейшим оповещением клиента о статусе заказа? Об этом под катом. (только я наверное кат ставлю, даже Рыжиков этого не делает, грешник)
Обновлено: делает текст ниже устаревшим и ненужным.
[spoiler]
Суть в том, что вставить в каждое письмо такую ссылку, уникальную, при клике на которую пользователь бы автоматически авторизовывался на ресурсе под своим логином. Замечу, что он даже может и не знать своего пароля.
Я назвал эту технологию "ссылки автовхода". Рассмотрим на примере оповещений в техподдержку. Только сразу скажу, данный пример подойдет только для уникальных e-mail'ов, эту технологию вы можете настроить в главном модуле. Если ваш проект уже достаточно взрослый и там много пользователей и встречаются дубли e-mail'ов, то данная технология будет работать некорректно и требует доработки напильником.
Теперь как это сделать.
1. Добавляем доп.свойство пользователям под названием "Хеш-код", тип "строка", код "UF_HASH_CODE". Остальное на ваше усмотрение. Я бы добавил "Не разрешать редактирование пользователем".
2. Добавляем обработчик на добавление пользователя.
Вот и все. Теперь каждый новый пользователь имеет свой уникальный код. Можете добавить соль и сам хеш сделать каким угодно. На дальнейшие шаги не влияет никак.
Только тут минус. Если у вас уже есть пользователи, то им надо будет отдельно проставить хеши. Если мало, то вручную, если много, то пробежаться сркиптом.
3. Редактируем почтовые шаблоны. Я покажу на примере "TICKET_CHANGE_BY_SUPPORT_FOR_AUTHOR"
Вот что я добавил в футере письма:
Тип html. Вот что получилось в итоге:
Собственно я к каждой ссылки, по которой требуется авторизация приплюсовал authologin=#AUTHOLOGIN_HASH#.
4. Добавляем еще один обработчик, который бы наполнял эти маркеры перед отправкой письма.
Тут подход индивидуальный. Смотрим нужный тип и наполняем ссылки. Лучше обратиться к специалисту. Вообще, вся данная статья скорее для опытных разработчиков, чем для конечных администраторов.
5. Ну собственно все. Пользователю ушло письмо с уникальным кодом. Он может уже не заморачиваться о логинах и паролях. Только нам осталось авторизовать приходящих по таким ссылкам.
Вот и все. И пусть пользователь хоть несколько раз делает заказ под гостем или пишет обращение в ТП под гостем. Все эти объекты будут суммироваться его e-mail'ом, на который он будет получать уникальные для себя ссылки автовхода.
Теперь по поводу безопасности. Да, если уникальная ссылка попадет в руки злоумышленника, то он сможет авторизоваться на ресурсе. Но ссылка приходит только на e-mail пользователя. Если хакер получил к нему доступ, то он и так авторизуется на ресурсе, если захочет.
В данном примере рассмотрено взаимодействие клиента и ТП. Если кому-то интересно, могу рассказать как сделать компоненту "Задать вопрос", которая будет принимать сообщения даже от неавторизованного пользователя и слать их в ТП. А клиент будет общаться с ТП посредством таких ссылок и полностью сохранит всю историю переписки.
Обновлено: делает текст ниже устаревшим и ненужным.
[spoiler]
Суть в том, что вставить в каждое письмо такую ссылку, уникальную, при клике на которую пользователь бы автоматически авторизовывался на ресурсе под своим логином. Замечу, что он даже может и не знать своего пароля.
Я назвал эту технологию "ссылки автовхода". Рассмотрим на примере оповещений в техподдержку. Только сразу скажу, данный пример подойдет только для уникальных e-mail'ов, эту технологию вы можете настроить в главном модуле. Если ваш проект уже достаточно взрослый и там много пользователей и встречаются дубли e-mail'ов, то данная технология будет работать некорректно и требует доработки напильником.
Теперь как это сделать.
1. Добавляем доп.свойство пользователям под названием "Хеш-код", тип "строка", код "UF_HASH_CODE". Остальное на ваше усмотрение. Я бы добавил "Не разрешать редактирование пользователем".
2. Добавляем обработчик на добавление пользователя.
AddEventHandler("main", "OnBeforeUserAdd", "OnBeforeUserAddHandler");
function OnBeforeUserAddHandler(&$arFields)
{
$hash = md5(time().mktime());
$arFields["UF_HASH_CODE"] = $hash;
}
|
Вот и все. Теперь каждый новый пользователь имеет свой уникальный код. Можете добавить соль и сам хеш сделать каким угодно. На дальнейшие шаги не влияет никак.
Только тут минус. Если у вас уже есть пользователи, то им надо будет отдельно проставить хеши. Если мало, то вручную, если много, то пробежаться сркиптом.
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. Добавляем еще один обработчик, который бы наполнял эти маркеры перед отправкой письма.
AddEventHandler("main", "OnBeforeEventAdd", "OnBeforeEventAddHandler");
function OnBeforeEventAddHandler(&$event, &$lid, &$arFields)
{
if ($event=="TICKET_NEW_FOR_AUTHOR" || $event=="TICKET_CHANGE_BY_SUPPORT_FOR_AUTHOR")
{
$rsUser = CUser::GetList(
$by="id", $order="asc",
array("=EMAIL" => $arFields["OWNER_EMAIL"]),
array("SELECT" => array("UF_HASH_CODE"))
);
$arUser = $rsUser->GetNext();
$arFields["AUTHOLOGIN_HASH"] = $arUser["UF_HASH_CODE"];
}
}
|
Тут подход индивидуальный. Смотрим нужный тип и наполняем ссылки. Лучше обратиться к специалисту. Вообще, вся данная статья скорее для опытных разработчиков, чем для конечных администраторов.
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 пользователя. Если хакер получил к нему доступ, то он и так авторизуется на ресурсе, если захочет.
В данном примере рассмотрено взаимодействие клиента и ТП. Если кому-то интересно, могу рассказать как сделать компоненту "Задать вопрос", которая будет принимать сообщения даже от неавторизованного пользователя и слать их в ТП. А клиент будет общаться с ТП посредством таких ссылок и полностью сохранит всю историю переписки.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
