Сессия на стороне фронтенда
План статьи
1) Вводная часть
2) Как у меня сделана сессию на стороне фронтенда
3) Выводы
Вводная часть
Всем привет, меня зовут Александр, я являюсь фронтенд разработчиком с 4-х летним опытом работы. В этой статье я хотел поделится опытом создания функционала, который следит за вашей сессией в административной панели и в случае, если ваш токен авторизации становится не действительным, то перенаправляет вас на страницу авторизации.
В очередной раз хочу начать с предыистории. В статье будет идти речь об сессии построенной на токенах. В своей работе я очень долго не разбирался с вопросом об сессии на стороне, а именно как ее продлевать, потому что не хотел усложнять свои пет проекты. После того как я изучил вопрос продления сессии для своего бекенда, то мной было принято решение сделать продление сессии на стороне фронтенда, чтобы пользователь мог не вылелать регулярно с админки, но когда работает в ней — оставаться. Думаю, что задача здесь ясна, осталось теперь оговорить реализацию функционала.
В этом месте возникает еще один вопрос: а где хранить функционал управления сессии, чтобы определять, когда токен истек, когда он еще валиден, обновляет куки, удаляет старые куки. Я считаю, что этот функционал должен быть в отдельном вынесенном модуле или функции (может называться по разному), это нужно для того, чтобы функционал можно было переиспользовать. В моем пет проекте по блогу этот функционал используется в при продлении действия токенов авторизации, либо при запросах. По бекенду и так все понятно — он возвращает ответ, что текущий токен актуален, либо присылает новую пару токенов. В чем я еще уверен, так это в том, что хранить время жизни токена на стороне клиента нельзя, потому что эта информация относится к одной из самых важных — чем меньше важной информации на сайте, тем надежней. Если злоумышленник узнает время жизни токена, то ему будет проще взломать вашу административную панель, потому что он будет знать, когда у вас меняется токен.
Как у меня сделана сессию на стороне фронтенда
У себя в проекте я храню токены в локальной истории, в данном случае использую jwt и у меня хранится access и refresh токены. Всего на фронте может быть несколько сценариев:
- нет access и refresh токенов;
В этом случае пользователя сразу редиректим на страницу авторизации.
- нет access, есть refresh токенов;
При наличии актуального refresh токена можно получить новую пару ключей. В противном случае пользователя также редиректит на страницу авторизации.
- есть access токен;
При наличии accessToken получаем сценарий с наибольшей логикой, но не с самой тяжелой в плане реализации. Значит, сначала отсылаем запрос на актуальность accessToken. Если он актулен, то ничего не происходит. Если accessToken просрочен, то делаем запрос на актуальность refreshToken. Если этот токен актуален, то также ничего не происходит, в противном случае пользователя редиректит на страницу авторизации.
Последний сценарий подстраховачный, если первые три каким-то образом не сработают. Но это врядле будет, потому что вышеописанный функционал покрывает все случаи, которые могут произойти во время продления авторизации.
Выводы
В данной статье я с вами поделился своим мнением, каким образом можно реализовать авторизацию на сайте.
Больше статей в моем блоге. Спасибо, что дочитали и до новых встреч в следующих статьях.