предисловие
Недавно делал проект воспроизведения видео пока уезжал из дома.Изначально хотел развернуть его на сервер,но в результате сервер Али имеет только 2g2 ядер.У меня не было другого выбора, кроме как развернуть его на виртуальную машину.После весь проект был завершен После этого я написал некоторые мысли в блоге, когда подытожил его.Если у вас есть какие-либо вопросы, пожалуйста, оставьте сообщение~
В проектах, которые я сделал, я пришел к выводу, что прежде чем мы поговорим о дизайне входа в систему, нам нужно понять сеанс и файлы cookie.
session
Поскольку протокол http не имеет состояния, мы не можем знать, в каком состоянии находится клиент при доступе к серверу, поэтому существуют сеансы и файлы cookie. Сеанс хранится на сервере. Через сеанс мы можем узнать состояние сеанса клиента. , сеанс Соответствует HttpSession в java, сеанс будет создан при создании getSession и связанный с ним идентификатор сеанса. Сеанс ответит http. При следующем запросе идентификатор сеанса будет включен в http заголовок, и сервер получит соответствующий идентификатор сеанса в соответствии с идентификатором sessionId.id для получения соответствующего сеанса. Поскольку сессия хранится на стороне сервера, также будут проблемы: 1. В режиме кластера необходимо выполнить синхронизацию передачи на сессии 2. Сессия будет потреблять хранилище на стороне сервера.
cookie
Сам протокол HTTP не имеет состояния. Что такое stateless, то есть сервер не может определить личность пользователя. Файл cookie на самом деле представляет собой небольшой фрагмент текстовой информации (формат «ключ-значение»). Клиент инициирует запрос к серверу, и если серверу необходимо записать статус пользователя, он использует ответ для выдачи файла cookie браузеру клиента. Браузер клиента сохранит файл cookie. Когда браузер снова запрашивает веб-сайт, браузер отправляет запрошенный URL-адрес на сервер вместе с файлом cookie. Сервер проверяет файл cookie, чтобы определить статус пользователя.
Разобравшись с сеансом и куки, давайте взглянем на концепцию jwt.
дизайн входа
В схеме дизайна есть два вида, один иsessionсвязаны, другой сcookieСвязанные, давайте представим их по очереди:
дизайн сеанса
мы используемsessionВ качестве флага входа будут проблемы с потреблением памяти и согласованностью кластера. Чтобы решить эту проблему, мы можем сохранить sessionId в Redis в качестве токена. Блок-схема выглядит следующим образом:
Когда запрос браузера поступает на доступ к серверу, он сначала пройдет через шлюз.В шлюзе мы создаем фильтр для фильтрации запроса, чтобы увидеть, передается ли токен в запросе.Если токен передается, то перейдите к redis проверить существует ли он.Если есть, то цепочка.Фильтр освобождается.Если токен не существует или не существует в redis, значит сессия устарела и нужно авторизоваться заново.При этом время передняя часть перейдет к интерфейсу входа, и этот запрос получит доступ к службе пользователя. После проверки правильности имени пользователя и пароля передайте HttpSession.getSession(), получите сеанс, затем используйте имя компании + sessionId как ключ, информацию о пользователе в качестве значения и сохраните ее в Redis, sessionId возвращается на внешний интерфейс в виде токена, и внешний интерфейс принесет sessionId при следующем доступе, чтобы мы могли определить, следует ли пользователю авторизоваться или нет, преимущества такой дизайнерской идеи заключаются в том, что сессия передается синхронно, что снижает нагрузку на сервер и доступ к пользовательскому сервису, не нужно каждый раз проверять правильность имени пользователя и пароля. Недостаток в том, что хотя сессия хранится в redis, но это, несомненно, увеличивает сложность системы.Сессия зависит от куки, но мобильный терминал часто не имеет куки, и если браузер использует только куки , идентификатор сеанса необходимо добавить после URL-адреса.
В понимании, основанном наcookieПрежде чем войти в систему, нам нужно понятьJWT
JWT
tokenКонкретная реализация , полное имя которойJSON Web Token, адрес официального сайта:jwt.io/, весь формат json, JWT состоит из трех частей:
标头(Заголовок включает тип токена (например, JWT) и используемый алгоритм хеширования (например, RSA))
负载(Первое место для хранения достоверной информации, такой как эмитент, время истечения срока действия, также может быть настроено (например, основная информация о пользователе))
签名(Подпись, эта часть предотвращает подделку jwt, эта часть кодирует первые две части с помощью base64url)
Алгоритм асимметричного шифрования
При шифровании и дешифровании используются разные ключи: один в качестве открытого открытого ключа, а другой — в качестве закрытого ключа. Информация, зашифрованная открытым ключом, может быть расшифрована только закрытым ключом. Информация, зашифрованная закрытым ключом, может быть расшифрована только открытым ключом.
Распространенные алгоритмы асимметричного шифрования: RSA, ECC
дизайн печенья
Это авторизация входа, которую я использовал, когда работал над предыдущим проектом. Безопасность файлов cookie всегда была проблемой. Хотя установка HttpOnly в true может предотвратить кражу информации сценариями js, нам все равно нужно зашифровать токен для обеспечения безопасности. информация пользователя.безопасность, схема конструкции выглядит следующим образом:
За исключением службы авторизации, открытый ключ хранится в каждом файле конфигурации службы, а соответствующий закрытый ключ хранится в службе авторизации.Когда запрос поступает через шлюз, фильтр в шлюзе расшифровывает токен с помощью открытого ключа. , и расшифровка прошла успешно.Затем обновить время истечения токена в куке,вернуть 200,перейти в интерфейс,вернуться если расшифровка не удалась,зайти в сервис авторизации после авторизации в интерфейсе входа,зайти в авторизацию службы, сначала проверьте имя пользователя и пароль, а затем используйтеJWTИнструмент использует закрытый ключ для шифрования информации о пользователе, генерирует JwtToken и, наконец, записывает токен в файл cookie, устанавливает время истечения срока действия и устанавливает для httpOnly значение true, чтобы предотвратить сценарии js.