TL;DR
Если вы хотите сразу перейти к реализации, просто пропустите введение в начале и перейдите к разделу решений.
Мы используем серверную часть Node.js и переднюю часть React.js, файлы cookie, React-Router-Dom V6 и Axios.
Введение:
Если вы опытный Front-End разработчик или даже младший разработчик, вы должны были уже бороться с некоторыми веб-приложениями с множеством защищенных маршрутов, которые пользователи должны авторизоваться, чтобы получить доступ к приложению, и такие приложения очень распространены в наши дни, особенно панели мониторинга со строгой аутентификацией за ними.
Поскольку я много боролся с тем, как защитить приложение React.js CSR (рендеринг на стороне клиента) и не использовать LocalStorage или файлы cookie для хранения высококонфиденциальной информации, такой как токены доступа, данные пользователя или что-либо, связанное с ними, из-за меньше безопасности у LS или файлов cookie, в то время как они могут быть атакованы посторонним с использованием кода javascript из внешних источников, таких как наиболее известные XSS (межсайтовый скриптинг) или CSRF (межсайтовый запрос-подделка). Настоятельно рекомендуется используйте память ваших Javascripts (например, Redux) для внутреннего хранения этих высококонфиденциальных данных, чтобы предотвратить такие методы взлома для доступа к этой информации, но у этого есть большой недостаток.
Проблема:
Если вы храните всю информацию, связанную с аутентификацией пользователя, в памяти ваших веб-приложений, то при каждом жестком обновлении браузера, смене вкладок, переходе назад и вперед с помощью кнопок, управляемых браузером, и т. д., все они будут стерты и удалены. у вас нет токена доступа или любых других данных, поэтому ваши пользователи должны снова войти в ваше приложение, и этот цикл будет продолжаться и продолжаться.
Это сильно повлияет на опыт ваших пользователей во время их использования, и они не будут довольны этим!
Решение:
После долгих исследований я нашел правильное решение для них. Я пришел к идее по-прежнему хранить все конфиденциальные данные в памяти приложений, но найти способ обойти исключения, такие как жесткое обновление или любое другое действие. это может привести к удалению состояния приложений.
Жетоны обновления — это то, что вам нужно!
Я создал приведенную выше архитектуру для примера приложения React.js для рендеринга на стороне клиента, которое имеет центральное хранилище, такое как Redux.
Как вы можете видеть, у нас есть сервер, который каждый раз, когда мы входим в систему, мы отправляем HTTP-запрос к нашему серверному приложению, чтобы проверить и получить все эти конфиденциальные данные, такие как токен доступа и данные пользователя.
Если мы запросим вход в систему, мы вернем наш токен и токен обновления, важная часть здесь: сервер должен установить HTTP-только и безопасный файл cookie для нашего браузера, содержащий данные токена обновления.
С другой стороны, как только мы вошли в систему, мы сохраняем все данные, такие как токен и информацию о пользователе, внутри нашего внутреннего состояния приложения, и теперь у нас есть безопасный файл cookie только для HTTP в наших файлах cookie.
Нам нужно создать оболочку для всех наших защищенных маршрутов на верхнем уровне нашего приложения, когда мы определяем наши маршруты с помощью этого компонента-оболочки, который запрашивает токен обновления, когда наше приложение не имеет аутентификации в своей памяти, что произойдет только один раз, когда приложение монтируется на DOM.
Прежде всего, мы создаем наш хук useRefreshToken следующим образом:
Затем мы создадим нашу оболочку, о которой я упоминал ранее, чтобы следить за аутентификацией:
И, наконец, это все, теперь вы можете сохранять данные вашего пользователя и токен доступа в памяти ваших приложений, не беспокоя ваших пользователей о входе в систему каждый раз, когда память приложения стирается, и вы также защитили свои особо конфиденциальные данные от хакеров, которые могут захотеть чтобы повредить ваше приложение!
Примечание 1. Не забывайте, что ваш сервер должен вернуть вам новый токен доступа и все важные данные, необходимые для вашего приложения, с помощью токена обновления так же, как и при входе в систему.
Примечание 2.Если у вас очень конфиденциальное приложение, такое как веб-приложение банка или что-то подобное, требующее еще одного уровня безопасности, вы можете по-прежнему использовать память, но заставлять людей входить в систему после любое необычное поведение, такое как жесткое обновление или нажатие кнопок «назад» и «вперед», потому что для этих вариантов использования требуется другой уровень безопасности, и вы не хотите рисковать новым входом/выходом из системы для лучшего взаимодействия с пользователем в банковских приложениях!
