Cookie, Session, Token, JWT, которые невозможно отличить по глупости

Что такое аутентификация (Аутентификация)

С точки зрения непрофессионала этоПодтвердить личность текущего пользователя, чтобы доказать, что «вы — это вы сами» (например: вам нужно вводить отпечаток пальца каждый день, когда вы идете на работу и с работы. Когда ваш отпечаток совпадает с отпечатком пальца, введенным в систему, перфорация прошла успешно)
Аутентификация в Интернете:
- логин пароль логин
- Ссылка для входа по электронной почте
- Номер мобильного телефона для получения кода подтверждения
- Пока вы можете получить электронное письмо / код подтверждения, вы являетесь владельцем учетной записи по умолчанию.

Что такое авторизация

Пользователь предоставляет стороннему приложению разрешение на доступ к определенным ресурсам пользователя.
- Когда вы устанавливаете мобильное приложение, APP спросит, предоставлено ли разрешение (разрешение на доступ к альбомам, географическому местоположению и т. д.)
- Когда вы посещаете апплет WeChat, когда вы входите в систему, апплет спросит, предоставлено ли разрешение (получите личную информацию, такую как псевдоним, аватар, регион, пол и т. д.)
Способы авторизации: cookie, сеанс, токен, OAuth.

Что такое учетные данные (Credentials)

Предпосылки для реализации аутентификации и авторизациипотребность вСредний (Сертификат)отметить посетителя
- В период Воюющих царств Шан Ян реформировал и изобрел самозваную почту. Наклейка с фотографией, выданная правительством, представляет собой гладкую и тщательно отполированную бамбуковую доску с выгравированным на ней портретом владельца и информацией о месте рождения. У китайцев он должен быть, если нет, то он считается черным домом, или шпионом, или чем-то в этом роде.
- В реальной жизни у каждого будет свойУдостоверение личности резидента, это юридическая форма, используемая для подтверждения личности владельцадокументы. С помощью удостоверения личности мы можем подать заявку на получение карты мобильного телефона/банковской карты/личного кредита/путешествия и т. д. ЭтоАутентифицированные учетные данные.
- В интернет-приложениях обычные веб-сайты (такие как Nuggets) будут иметь два режима: режим посетителя и режим входа в систему. В туристическом режиме вы можете просматривать статьи на веб-сайте в обычном режиме.Если вы хотите поставить лайк/избранное/поделиться статьей, вам необходимо войти в систему или зарегистрировать учетную запись. Когда пользователь успешно входит в систему, сервер выдает токен браузеру, используемому пользователем.Этот токен используется для идентификации вашей личности.Каждый раз, когда браузер отправляет запрос, он приносит этот токен, и вы можете его использовать. недоступно в гостевом режиме.

Что такое файлы cookie

HTTP - это протокол без сохранения состояния (для обработки транзакций без памяти каждый раз, когда сеанс клиента и сервера завершается, сервер не сохраняет никакой информации о сеансе).): Каждый запрос полностью независим, сервер не может подтвердить идентификационную информацию текущего посетителя и не может отличить, является ли отправитель предыдущего запроса и отправитель этого времени одним и тем же лицом. Следовательно, чтобы отслеживать сеанс (чтобы знать, кто меня посещает), сервер и браузер должны активно поддерживать состояние, которое используется, чтобы сообщить серверу, исходят ли два запроса до и после от одного и того же браузера. И это состояние должно быть достигнуто через cookie или сеанс.
Файлы cookie хранятся на стороне клиента:Файл cookie – это небольшой фрагмент данных, который сервер отправляет в браузер пользователя и сохраняет его локально. Он будет перенесен и отправлен на сервер при следующем запросе браузера к тому же серверу.
Файлы cookie не являются междоменными:Каждый файл cookie привязан к одному доменному имени и не может быть получен и использован под другими доменными именами.Разрешено совместное использование между доменными именами первого и второго уровня.(В зависимости от домена).

Важные свойства файлов cookie

Атрибуты	иллюстрировать
name=value	Пара ключ-значение, имя установленного файла cookie и соответствующее значение должны бытьТип строки - Если значение является символом Unicode, требуется кодировка символов. - Если значение представляет собой двоичные данные, необходимо использовать кодировку BASE64.
domain	Укажите доменное имя, которому принадлежит файл cookie, по умолчанию используется текущее доменное имя.
path	Указывает путь (маршрут), по которому cookie вступает в силу, по умолчанию '/'. Если установлено`/abc`, тогда только`/abc`Следующие маршруты могут получить доступ к файлу cookie, например:`/abc/read`.
maxAge	Срок действия файла cookie в секундах. Если целое число, срок действия файла cookie истекает через maxAge секунд. Если это отрицательное число, файл cookie является временным файлом cookie, который становится недействительным при закрытии браузера, и браузер не сохраняет файл cookie в какой-либо форме. Если он равен 0, это означает удаление файла cookie. По умолчанию -1. - Лучше, чем истекает.
expires	Срок действия, срок действия файла cookie истекает через установленный момент времени. Как правило, файлы cookie браузера сохраняются по умолчанию. Когда браузер закрывается для завершения сеанса, файл cookie также удаляется.
secure	Передается ли файл cookie только с использованием безопасного протокола. Протоколы безопасности включают HTTPS, SSL и т. д., которые шифруют данные перед их передачей по сети. По умолчанию ложно. Если для параметра secure установлено значение true, файл cookie недействителен для HTTP и действителен только для HTTPS.
httpOnly	Если для файла cookie установлен атрибут httpOnly, информация файла cookie не может быть прочитана с помощью сценария JS, но файл cookie по-прежнему можно изменить вручную через приложение, поэтому он может только предотвратить атаки XSS в определенной степени, а не абсолютную безопасность.

Что такое сессия

сеанс — это еще один механизм для записи состояния сеанса сервера и клиента.
Сессия реализована на основе файлов cookie, сессия хранится на стороне сервера, а sessionId будет храниться в файле cookie клиента.

Процесс аутентификации сеанса:
- Когда пользователь запрашивает сервер в первый раз, сервер создает соответствующий сеанс в соответствии с соответствующей информацией, предоставленной пользователем.
- Когда запрос возвращается, уникальная идентификационная информация SessionID этого сеанса возвращается в браузер.
- После того, как браузер получит информацию SessionID, возвращенную сервером, он сохранит эту информацию в файле cookie, а файл cookie запишет, какому доменному имени принадлежит этот SessionID.
- Когда пользователь посещает сервер во второй раз, запрос автоматически определит, есть ли информация о файлах cookie под этим доменным именем.Если есть, информация о файлах cookie также будет автоматически отправлена на сервер, сервер получит SessionID из cookie, а затем найдите соответствующую сессию в соответствии с SessionID. Если информация не найдена, это означает, что пользователь не вошел в систему или логин недействителен. Если сессия найдена, это доказывает, что пользователь вошел в систему и может выполнять следующие операции.

В соответствии с вышеописанным процессом видно, чтоSessionID — это мост, соединяющий Cookie и Session, большинство систем также используют этот принцип для проверки статуса входа пользователя.

Разница между файлом cookie и сеансом

безопасность:Session более безопасен, чем Cookie, Session хранится на стороне сервера, а Cookie хранится на стороне клиента.
различные типы значений доступа: Cookie поддерживает хранение только строковых данных. Если вы хотите установить другие типы данных, вам необходимо преобразовать их в строку. Сессия может хранить данные любого типа.
Срок действия разный:Файлы cookie могут храниться в течение длительного времени, например, функция входа по умолчанию, которую мы часто используем, срок действия сеанса обычно истекает в течение короткого времени, а клиент закрывается (по умолчанию) или время ожидания сеанса истекает.
Размеры хранения варьируются:Данные, хранящиеся в одном файле cookie, не могут превышать 4 КБ, а сеанс может хранить гораздо больше данных, чем файл cookie, но при слишком большом количестве посещений он будет занимать слишком много ресурсов сервера.

Что такое токен

Acesss Token

Учетные данные ресурса, необходимые для доступа к интерфейсу ресурсов (API)
Состав простого токена:uid (уникальный идентификатор пользователя), time (временная метка текущего времени), sign (подпись, первые несколько цифр токена представляют собой шестнадцатеричную строку определенной длины, сжатую алгоритмом хеширования)
Функции:
- Без сохранения состояния на стороне сервера, хорошая масштабируемость
- Поддержка мобильных устройств
- Безопасность
- Поддержка межпрограммных вызовов
Процесс аутентификации токена:

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

Каждый запрос должен содержать токен, и токен должен быть помещен в заголовок HTTP.
Аутентификация пользователей на основе токенов — это метод аутентификации без сохранения состояния на стороне сервера, и стороне сервера не нужно хранить данные токенов. Время вычисления парсинга токена обменивается на место для хранения сессии, тем самым снижая нагрузку на сервер и уменьшая частые запросы к базе данных
Токен полностью управляется приложением, поэтому он может избежать политики одного и того же происхождения.

Refresh Token

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

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

Разница между токеном и сеансом

Сессия – этоМеханизм для записи состояния сеанса сервера и клиента, обеспечения состояния сервера и записи информации о сеансе.. И токенжетон,Учетные данные ресурса, необходимые для доступа к интерфейсу ресурсов (API). ТокенДелает сервер без состояния и не сохраняет информацию о сеансе.
Сеанс и токен не являются противоречивыми, поскольку безопасность аутентификации токена лучше, чем сеанс, поскольку каждый запрос имеет подпись, но также предотвращает прислугу к прилавками и воспроизведению, а сеанс должен опираться на слой связи для защиты безопасности коммуникаций.Если вам нужно реализовать сеансы с отслеживанием состояния, вы все равно можете добавить сеанс, чтобы сохранить некоторое состояние на стороне сервера.
Так называемая сеансовая аутентификация просто сохраняет информацию о пользователе в сеансе.Из-за непредсказуемости идентификатора сеанса в настоящее время он считается безопасным. А Token , если он относится к OAuth Token или аналогичному механизму, обеспечивает аутентификацию и авторизацию, аутентификация предназначена для пользователей, а авторизация — для приложения. Его цель — дать приложению право доступа к информации пользователя. Токен здесь уникален. Его нельзя передать другим приложениям или другим пользователям. Сессия обеспечивает только простую аутентификацию, то есть, пока существует этот SessionID, считается, что он имеет все права этого Пользователя. Это должно быть строго конфиденциально, эти данные должны храниться только на сайте и не должны передаваться другим веб-сайтам или сторонним приложениям. Итак, простыми словами:Если ваши пользовательские данные могут быть переданы третьим лицам или разрешить третьим лицам вызывать API-интерфейсы, используйте Token . Если это всегда только ваш собственный веб-сайт, ваше собственное приложение, не имеет значения, что вы используете.

Что такое JWT

JSON Web Token (сокращенно JWT) в настоящее время является самым популярнымСертификация по перекрестным доменамрешение.
этоМеханизм аутентификации и авторизации.
JWT предназначен для использования между средами веб-приложений.заявление о пропускеи реализует открытый стандарт на основе JSON (RFC 7519). Утверждения JWT обычно используются для передачи информации об удостоверении пользователя, прошедшей проверку подлинности, между поставщиками удостоверений и поставщиками услуг для получения ресурсов с серверов ресурсов. Например, он используется для входа пользователя.
JWT может быть подписан с использованием алгоритма HMAC или открытых/закрытых ключей RSA. Из-за существования цифровых подписей этой передаваемой информации доверяют.
Учитель Руан ИфэнНачало работы с веб-токеном JSONЭто очень просто и легко понять, поэтому я не буду поднимать здесь шумиху.

Сгенерировать JWT

jwt.io/
www.jsonwebtoken.io/

Принцип JWT

Процесс аутентификации JWT:
- Пользователь вводит имя пользователя/пароль для входа в систему. После успешной аутентификации сервера он вернет клиенту JWT.
- Клиент сохраняет токен локально (обычно с использованием локального хранилища, но также и с помощью файлов cookie).
- Когда пользователь хочет получить доступ к защищенному маршруту или ресурсу, ему необходимо использовать режим Bearer, чтобы добавить JWT в поле Authorization заголовка запроса.Содержимое выглядит следующим образом

Authorization: Bearer <token>

Маршрут защиты на стороне сервера проверит информацию JWT в заголовке запроса Authorization и, если это законно, разрешит поведение пользователя.
Поскольку JWT является автономным (с некоторой информацией о сеансе внутри), это снижает необходимость запрашивать базу данных.
Поскольку JWT не использует файлы cookie, вы можете использовать любое доменное имя для предоставления своих услуг API, не беспокоясь о совместном использовании ресурсов между источниками (CORS).
Это механизм аутентификации без сохранения состояния, поскольку состояние пользователя больше не хранится в памяти сервера.

Как используются JWT

Клиент получает возвращенный сервером JWT, который может быть сохранен в файле cookie или в локальном хранилище.

метод первый

Когда пользователь хочет получить доступ к защищенному маршруту или ресурсу, он может быть автоматически отправлен в файле cookie, но он не может быть междоменным, поэтому лучше поместить его в поле Авторизация заголовка HTTP-запроса и использовать режим Bearer. Добавьте ЮВТ.
```
GET /calendar/v1/events
Host: api.example.com
Authorization: Bearer <token>
```
- Состояние пользователя не сохраняется в памяти сервера, что являетсяМеханизм аутентификации без сохранения состояния
- Маршрут защиты на стороне сервера проверит информацию JWT в заголовке запроса Authorization, и, если она действительна, поведение пользователя будет разрешено.
- Поскольку JWT является автономным, это снижает потребность в запросах к базе данных.
- Эти функции JWT позволяют нам полностью полагаться на его природу без сохранения состояния для предоставления услуг API данных или даже для создания службы потоковой загрузки.
- Поскольку JWT не использует файлы cookie, вы можете обслуживать свой API, используя любое доменное имя, неНе нужно беспокоиться о совместном использовании ресурсов между источниками(КОРС)

Способ 2

В междоменном режиме вы можете поместить JWT в тело данных POST-запроса.

способ третий

Передача через URL

http://www.example.com/user?token=xxx

Использование JWT в проекте

адрес проекта

Разница между токеном и JWT

такой же:

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

разница:

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

Общие внешние и внутренние методы аутентификации

Session-Cookie
Проверка токена (включая JWT, SSO)
OAuth2.0 (открытая авторизация)

Общие алгоритмы шифрования

Алгоритм хеширования, также известный как хэш-алгоритм, хеш-функция, хеш-функция, представляет собой метод создания небольших цифровых «отпечатков пальцев» из любых данных. Алгоритмы хеширования перемешивают данные вместе, чтобы воссоздать хэш-значение.
Алгоритм хеширования в основном используется для обеспечения подлинности (т.е. целостности) данных, то есть отправитель отправляет исходное сообщение и хеш-значение вместе, а получатель использует ту же хеш-функцию для проверки подлинности исходных данных.
Алгоритмы хеширования обычно имеют следующие характеристики:
- Как и быстро: необработанные данные можно быстро хэшировать
- Обратная сложность: практически невозможно получить исходные данные из хеш-значения.
- Чувствительность ввода: пока исходные данные немного меняются, полученное значение хеш-функции сильно отличается.
- Предотвращение столкновений: трудно найти разные исходные данные, чтобы получить одно и то же значение хеш-функции, количество атомов во Вселенной составляет около 10 в 60-й степени в 80-й степени, поэтому 2 в 256-й степени достаточно для размещения всех возможностей. , Когда алгоритм хорош, вероятность столкновения столкновения очень мала:
  - 2 в 128-й степени равно 340282366920938463463374607431768211456, что равно 10 в 39-й степени.
  - 2 в 160-й степени равно 1,4615016373309029182036848327163e+48, что равно 10 в 48-й степени.
  - 2 в 256-й степени равно 1,1579208923731619542357098500869 × 10 в 77-й степени, то есть 10 в 77-й степени.

Уведомление:

Вышеупомянутое не гарантирует, что данные были злонамеренно изменены.И исходные данные, и хеш-значение могут быть злонамеренно изменены.Чтобы гарантировать, что они не будут изменены, можно использовать схему открытого и закрытого ключей RSA в сочетании. со значением хеша.
Алгоритм хеширования в основном используется для предотвращения ошибок при передаче компьютера.Ранние компьютеры гарантировались 8-битным кодом проверки четности первых 7 битов данных (низкая эффективность отходов 12,5%).Для фрагмента данных или файла это генерируется алгоритмом хеширования.128-битное или 256-битное хеш-значение, если есть проблема с проверкой, требуется повторная передача.

Общая проблема

Вопросы, которые следует учитывать при использовании файлов cookie

Поскольку он хранится на клиенте, клиент может легко подделать его, и перед использованием необходимо проверить законность.
Не храните конфиденциальные данные, такие как пароли пользователей, балансы счетов.
Используйте httpOnly для некоторого повышения безопасности
Минимизируйте размер файлов cookie, а объем сохраняемых данных не может превышать 4 КБ.
Установите правильный домен и путь, чтобы уменьшить передачу данных
Файлы cookie не могут быть междоменными
Браузер может хранить до 20 файлов cookie для веб-сайта, а браузеры обычно позволяют хранить только 300 файлов cookie.
Мобильный терминал не очень хорошо поддерживает файлы cookie, и сеанс должен быть реализован на основе файлов cookie, поэтому мобильный терминал обычно использует токен.

Вопросы, которые следует учитывать при использовании сеансов

Храните сессию на сервере, когда в сети одновременно много пользователей, эти сессии будут занимать много памяти, и необходимо периодически очищать просроченные сессии на стороне сервера.
Когда сайт используетРазвертывание кластераПри его использовании вы столкнетесь с проблемой разделения сеансов между несколькими веб-серверами. Поскольку сеанс создается одним сервером, но сервер, обрабатывающий запрос пользователя, не обязательно является сервером, создавшим сеанс, сервер не может получить информацию, такую как учетные данные для входа, которые были введены в сеанс ранее.
Когда несколько приложений хотят совместно использовать сеансы, в дополнение к вышеуказанным проблемам они также столкнутся с междоменными проблемами, поскольку разные приложения могут быть развернуты на разных хостах, а обработка междоменных файлов cookie должна выполняться в каждом приложении.
sessionId хранится в куки, что если браузер запрещает куки или не поддерживает куки?Как правило, за sessionId следует параметр url для перезаписи URL-адреса, поэтому сеанс не обязательно должен быть реализован с помощью файла cookie.
Мобильный терминал не очень хорошо поддерживает файлы cookie, и сеанс должен быть реализован на основе файлов cookie, поэтому мобильный терминал обычно использует токен.

Вопросы, которые следует учитывать при использовании токенов

Если вы считаете, что использование базы данных для хранения маркера приведет к тому, что время запроса будет слишком большим, вы можете сохранить его в памяти. Например, Redis очень подходит для ваших потребностей в запросе токена.
Токен полностью управляется приложением, поэтому он может избежать политики одного и того же происхождения.
Токены могут избежать CSRF-атак (поскольку файлы cookie не нужны)
Мобильный терминал не очень хорошо поддерживает файлы cookie, и сеанс должен быть реализован на основе файлов cookie, поэтому мобильный терминал обычно использует токен.

Вопросы, которые следует учитывать при использовании JWT

Поскольку JWT не использует файлы cookie, вы можете использовать любое доменное имя для предоставления своих услуг API, не беспокоясь о совместном использовании ресурсов между источниками (CORS).
JWT не зашифрован по умолчанию, но его можно зашифровать. После создания исходного токена его можно снова зашифровать с помощью ключа.
Секретные данные не могут быть записаны в JWT без шифрования JWT.
JWT можно использовать не только для аутентификации, но и для обмена информацией. Эффективное использование JWT может сократить количество запросов сервера к базе данных.
Самым большим преимуществом JWT является то, что серверу больше не нужно хранить сеанс, так что аутентификация сервера и бизнес аутентификации могут быть легко расширены. Но это также самый большой недостаток JWT: поскольку серверу не нужно хранить состояние сеанса, невозможно сбросить токен или изменить разрешения токена во время использования. То есть после выдачи JWT он останется действительным до истечения срока его действия, если только сервер не развернет дополнительную логику.
Сам JWT содержит информацию об аутентификации, и после утечки любой может получить все разрешения токена. Чтобы уменьшить кражу, срок действия JWT должен быть относительно коротким. Для некоторых более важных разрешений пользователи должны пройти повторную аутентификацию при их использовании.
JWT подходит для одноразовой проверки подлинности команды, и выдается JWT с очень коротким сроком действия.Даже если опасность выявляется, она очень мала.Поскольку для каждой операции генерируется новый JWT, нет необходимости сохранять JWT, и он действительно не имеет гражданства.
Чтобы уменьшить кражу, JWT не должен передаваться в виде простого текста с использованием протокола HTTP, а должен передаваться с использованием протокола HTTPS.

Вопросы для рассмотрения при использовании алгоритмов шифрования

никогда не берихранение открытого текстапароль
Всегда используйте хэш-алгоритм для обработки паролей, никогда не используйте Base64 или другую кодировку для хранения паролей, это то же самое, что хранить пароли в виде открытого текста, использовать хэширование, а не кодирование. Шифрование и шифрование являются двусторонними процессами, а пароль держится в секрете и должен быть известен только его владельцу, этот процесс должен быть односторонним. Именно для этого и используется хэш, никогда не бывает такого понятия, как расхеширование, но есть декодирование в кодировании, а в шифровании есть дешифрование.
Никогда не используйте слабый хеш или взломанный, например MD5 или SHA1, только надежный алгоритм хеширования пароля.
Никогда не показывайте и не отправляйте пароль в экспресс-форме, даже если владелец пароля должен быть таким. Если вам нужно «забыть пароль», вы можете случайным образом сгенерировать новый.один раз(это важно) пароль и отправьте этот пароль пользователю.

Схема совместного использования сеансов в распределенной архитектуре

1. Репликация сеанса

Когда сеанс на каком-либо сервере изменяется (добавляется, удаляется и модифицируется), узел сериализует все содержимое сеанса, а затем транслирует его всем другим узлам, независимо от того, нужен ли сеанс другим серверам или нет, чтобы обеспечить сеанс. синхронизация

преимущество:Отказоустойчивые сеансы между серверами могут отвечать в режиме реального времени.
недостаток:Это создаст определенное давление на сетевую нагрузку.Если объем сеанса большой, это может привести к перегрузке сети и снижению производительности сервера.

2. Стратегия привязки сеанса/IP-адреса

Используя механизм ip_hash в Ngnix, все запросы определенного ip направляются на один и тот же сервер, то есть пользователь привязывается к серверу.Когда пользователь запрашивает в первый раз, балансировщик нагрузки перенаправляет запрос пользователя на сервер A. Если балансировщик нагрузки устанавливает фиксированный сеанс, то каждый последующий запрос пользователя будет перенаправляться на сервер A, что эквивалентно пользователь и A. Сервер склеен, это механизм липкой сессии.

преимущество:Просто, не нужно ничего делать с сеансом.
недостаток:Отсутствие отказоустойчивости, в случае сбоя текущего сервера, к которому осуществляется доступ, при переносе пользователя на второй сервер информация о его сеансе будет недействительной.
Применимая сцена:Сбой оказывает меньшее влияние на клиентов; сбой сервера — событие с низкой вероятностью. .
Метод реализации:Взяв в качестве примера Nginx, липкую сессию можно реализовать, настроив атрибут ip_hash в вышестоящем модуле.

3. Совместное использование сеанса (обычно используется)

Используйте распределенную схему кэширования, такие как memcached, Redis для сеанса кэширования, но требует MeMCached Redis должен быть кластером или
Помещаем сессию в Redis для хранения, хотя архитектура усложняется, и требуется еще один визит в Redis, плюсы от этого решения тоже велики:
- Реализован обмен сессиями;
- Можно масштабировать по горизонтали (добавляя серверы Redis);
- Сервер перезапускает сеанс, не теряя его (но также обратите внимание на механизм обновления/аннулирования сеанса в Redis);
- Можно использовать не только для сеансов сервера, но и для разных платформ (таких как Интернет и APP).

4. Постоянство сеанса

Сохраните сеанс в базе данных, чтобы обеспечить постоянство сеанса.

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

Пока браузер закрыт, сессия действительно исчезает?

неправильно. Для сеанса, если только программа не уведомит сервер об удалении сеанса, сервер будет хранить его все время.Программа обычно отправляет инструкцию удалить сеанс, когда пользователь выходит из системы.
Однако браузер никогда активно не информирует сервер о том, что он будет закрыт перед закрытием, поэтому у сервера нет шансов узнать, что браузер был закрыт.Причина этой иллюзии заключается в том, что большинство механизмов сеанса используют файлы cookie сеанса для сохранения идентификатора сеанса. , а идентификатор сеанса исчезает после закрытия браузера, а исходный сеанс невозможно найти при повторном подключении к серверу. Если файл cookie, установленный сервером, сохраняется на жестком диске или используются какие-либо средства для перезаписи заголовка HTTP-запроса, отправленного браузером, и отправки исходного идентификатора сеанса на сервер, повторное открытие браузера может по-прежнему открыть исходный сеанс.
случаетсяПоскольку закрытие браузера не приведет к удалению сеанса, сервер вынужден установить время истечения срока действия для сеанса.Когда время, прошедшее с момента последнего использования сеанса клиентом, превышает это время истечения, сервер считает, что клиент прекратил деятельность. и будет удаление сеанса для экономии места для хранения.

адрес проекта

Используйте JWT в своем проекте

послесловие

В этой статье рассказывается только о теоретических знаниях, основанных на моем собственном понимании, потому что я не очень хорошо разбираюсь в знании бэкенда/алгоритма.Если есть какая-либо ошибка, пожалуйста, дайте мне знать, большое спасибо
Если эта статья была вам полезна, пожалуйста, поставьте лайк~~