Хабрахабр

Magic link или история о том, как мы упростили жизнь пользователю

В статье я поделюсь личным опытом разработки и реализации “волшебных ссылок”. Расскажу зачем они нужны в нашем проекте, как функционируют и в конце даже всплакну над тем, что отсутствие такого функционала в больших системах используемых мною заставляет меня гневно рвать на себе волосы.

основная цель статьи — рассказать про саму идею, а не показать то, насколько красив код. Код будет только в одном месте, т.к.

Вступительное бла бла бла

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

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

Какой у меня пароль?

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

Пользователи к этому никаких претензий не предъявляли. Изначально у нас нельзя было задать вопрос не будучи залогиненным. Изначально юристы реагировали медленно, т.к. В форме регистрации ввести ящик и пароль не оказалось проблемой. Получив ответ в системе и уведомление на свою почту, пришло время клиенту узнать что же там юрист такого написал. вопросов было не много, а потому клиент даже успевал забыть, что такой вопрос у него есть. банально забыли пароль. И тут наступает коллапс: бОльшая часть пользователей не осилила авторизацию, т.к. Мы стали терять клиентов… И не то, чтобы у нас не было формы восстановления пароля, но она не сильно помогала.

Хочу просто задать вопрос

Приняли решение, что можем открыть возможность создания вопроса для гостей. Клиент в форме создания сущности дополнительно вводит почтовый ящик и всё. Нет шага регистрации. Клиент захотел задать вопрос — он его задал.

Юрист, взяв в работу заданный гостем вопрос, даёт раскрытый обширный ответ с учётом всех кейсов… кхм… пишет пару строчек умных слов и всё — ответ дан.

нашпроект.ком алахомора!

Система отправляет клиенту уведомление о том, что на его вопрос был дан ответ. Но в письме появляется некая ссылка — magic link, при клике на которую происходит авторизация пользователя и он с довольным лицом оказывается на странице своего вопроса. Всё.

Тут и сказочке конец, а кто слушал молодец.

Теперь я расскажу о технической стороне этого “прогресса”.

Запили мне хэш

Проект состоит из 2х частей: фронт и бэк. На бэке был разработан сервис, который отвечает за работу системы magic link.

На уникальность hash, конечно же, проверяется. Изначально система генерирует рандомный набор из 6 символов (буквы + цифры) — hash, который сохраняет в базу.

позже такие ссылки стали приходить и юристам, у которых память на пароли ещё дырявее) и типа операции, в результате которого он был сгенерирован (ответ на вопрос, создание вопроса, комментарий и т.п.). У каждого хэша есть своё время жизни, которое зависит от роли пользователя, для которого он генерируется (т.к. мало и 6-символьный хэш, как показывает практика, пока себя вполне адекватно ведёт. Пользователей у нас в базе порядка 14 000, т.е. Мы решили, что 6 символов — идеальный вариант для запоминания или самостоятельного ввода в адресную строку, которая, к слову выглядит весьма красиво — /hash/haSH12. Хэши, у которых истёк срок действия удаляются.

Также он привязан к сущности (ID + тип), операция над которой вызвала генерацию хэша. Каждый хэш привязан к тому пользователю для которого он генерируется.

Если хэш валиден — происходит авторизация пользователя и последующий его редирект на детальный просмотр сущности. Переходя по magic link фронт отправляет на бэк хэш и ждёт в ответе указания что делать дальше. Если хэш не валиден — фронт просит пользователя авторизоваться.

Таким образом, хэш получил дополнительную настройку, которую мы назвали “локация” и в которой храним роут фронта с дополнительными параметрами (в данном случае ID комментария), на который происходит редирект пользователя после авторизации. Со временем развития платформы прилетело требование о том, что в случае операции комментирования пользователь, переходя по хэшу, должен скроллиться к новому комментарию.

Например, верифицировать профиль или запустить какой-то таймер дедлайна ответа на вопрос. Следующее развитие платформы потребовало возможность выполнения ряда операций перед тем, как пользователь будет авторизован. Система обработки хэшей, находя нужный хэш в базе, смотрит на наличие алиаса — обычная строка, которая хранит текстовую константу. Это подарило хэшу настройку с названием “алиас”. Если алиас есть, по нему система создаёт вызов метода, в котором и выполняются необходимые операции до того, как пользователь будет авторизован

public function executeAlias()
//camelCase alias $aliasMethod = Str::camel($this->hash->alias); if(!method_exists($this, $aliasMethod)){ return $this; } return $this->{$aliasMethod}();
}

Данная система по управлению хэшами настолько хорошо себя зарекомендовала, что мы её распространили на доступ к файлам. Ситуация простая: в вопросе клиент загружает файл, бэк сохраняет его у себя где-то там в тёмных недрах сервера, но пользователи (что клиент, что юрист) видят красивую ссылку /storage/hash12/some_CODE. Система по управлению файловыми хэшами при загрузке файла сразу генерирует пару хэш-код и к ним дополнительно привязывает путь к файлу и всё это сохраняет в базе.

Пользователь, переходя по magic link будет получать на телефон код и вводить его в предложенной фронтом форме. Код мы планируем интегрировать и для magic link, чтобы в будущем использовать его для двухфакторной авторизации.

Анализируя ситуацию, мы понимаем, что ошибки с неправильным вводом пароля и количество писем с напоминанием пароля почти сошли на “нет”. Данная система позволила нам настроить удобный и гибкий доступ пользователя к системе. Мы можем изменять время жизни каждого хэша отдельно или генерировать его для какого-то отдельно взятого пользователя по его запросу.

Плак, плак

И в конце всплакиваю. Всплакиваю от того, что сайты\платформы, которыми иногда пользуюсь такую систему не используют или в качестве хэша выступает строка из 40 символов, т.к. иногда есть необходимость не переходить по ссылке из письма, а ввести её вручную в адресной строке. Хотя, не отрицаю того, что с ростом нашего проекта когда-то и мы придём к длине такого хэша…

Спасибо за внимание.

S. P. напоминаю, что это личный опыт и я оставляю свой камушек в большом огороде информации.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть