Веб-логин, который интерфейс должен знать

JavaScript

Меня зовут Эр Донг, я могу написать интерфейс, смешанный с ByteDance, Meituan, работал интервьюером, хорошо разбираюсь в темах рабочего места программиста, алгоритмах, интерфейсе.
Есть техническая группа не вода, есть техническая группа не вода, обратите внимание на паблик "Программист Эрдонг" и тяните вас в группу

В первой половине 2022 года я собираюсь написать серию руководств по алгоритмам «Проведите 500 вопросов, чтобы попасть на большую фабрику».

Добро пожаловать в технический паблик: программист Erdong

Добро пожаловать на номер станции B: программист Эрдонг

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

После прихода в ByteDance внешний интерфейс редко касается событий после HTTP-запроса, а SDK, связанный с входом в систему, хорошо упакован, поэтому в этой статье мы просто изучим и запишем его.

Почему существует такая вещь, как вход в систему?

Во-первых, потому чтоHTTPЭто протокол без сохранения состояния, так называемое состояние без сохранения состояния означает, что сервер не сохраняет никаких данных между двумя запросами, что равносильно тому, что вы забываете о вас после того, как вы сказали человеку слово. Следовательно, вход в систему заключается в использовании какого-либо метода, позволяющего серверу распознавать вас между несколькими запросами, вместо того, чтобы каждый раз при отправке запроса вводить идентификационную информацию, такую ​​как имя пользователя и пароль. От процесса успешного входа в систему до выхода из системы сервер поддерживает структуру данных, которая может идентифицировать информацию о пользователе.В широком смысле этот процесс называется сеансом, то есть поддерживается сеанс.

Два общих логина

Я вдруг подумал об одном, прочитав много вопросов в интернете, я думаю, что каждый должен различать два понятия:Обобщенный сеансиузкая сессия

**Обобщенный сеанс: **Обобщенный сеанс – это процесс от успешного входа в систему до выхода из системы. Во время этого процесса клиент и сервер сохраняют статус входа. Что касается того, как поддерживать этот статус входа, требований нет. .

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

Сеанс сервера + идентификатор сеанса клиента

Сначала посмотрим на картинку:

Подробно, вот основные процессы:

  1. Клиент получает доступ к интерфейсу /login с именем пользователя и паролем.Сервер проверяет имя пользователя и пароль после их получения.Если проверка верна, отношение сопоставления между sessionId и сеансом будет сохранено на сервере.

  2. Сервер возвращает ответ и устанавливает sessionId на клиенте в форме set-cookie, так что sessionId существует на клиенте. Здесь следует отметить, что хранение sessionId в куке не является обязательным решением, но так обычно делают все, и при выполнении запроса в соответствии с доменом и путем он автоматически принесет куки, избавляя от необходимости ручное подключение процесс.

  3. Когда клиент инициирует запрос без входа в систему, сервер находит соответствующий сеанс с помощью идентификатора сеанса в файле cookie, чтобы узнать, кто отправил запрос.

token

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

Таким образом, самое существенное отличие от первого метода входа в систему заключается в том, что место для хранения сеанса обменивается на время расчета токена парсинга.

В отрасли обычно используется метод шифрования jwt (json web token), конкретный формат jwt показан на рисунке:

Кратко представим jwt, который в основном состоит из 3-х частей:

header 头部
{
  "alg": "HS256",
  "typ": "JWT"
}
payload 负载
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "exp": 1555341649998
}
signature 签名

Заголовок описывает алгоритм шифрования и тип токена, обычно это JWT;

Полезная нагрузка содержит информацию о пользователе, то есть информацию, которую необходимо поддерживать в сеансе на стороне сервера при первом методе входа в систему;

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

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

Короче говоря, окончательный jwt = base64url(заголовок) + «.» + base64url(полезная нагрузка) + «.» + подпись

jwt может быть возвращен в ответ или возвращен в файле cookie, что является специфическими методами возврата и не имеет значения.

Когда клиент инициирует запрос, официально рекомендуется поместить его в заголовок HTTP:

Authorization: Bearer <token>

Это действительно может решить проблему междоменных файлов cookie, но где их размещать, зависит от бизнес-сценария, и определенного правила нет.

Проблемы с двумя схемами входа

режим сеанса

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

  2. Количество сеансов увеличивается с количеством вошедших в систему пользователей, и объем хранилища значительно увеличивается.

  3. Способ хранения sessionId в session+cookie может иметь проблемы с атакой csrf.Общим способом является использованиеcsrf_tokenрешать

просто так

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

позже

Проясните концепцию с легкостью

--------------------------------------------

Категории