Состояние входа в систему, которое интерфейс должен понимать: Cookie, Session и Token.

HTTP
Состояние входа в систему, которое интерфейс должен понимать: Cookie, Session и Token.

Введение

каждый знает,HTTPЭто протокол без сохранения состояния, так как же веб-приложение сохраняет состояние входа пользователя?

если ты правcookie,sessionа такжеtokenЕсли вы не понимаете преимуществ и недостатков, или хотите узнать, как реализовать состояние входа на практике, то эта статья будет вам очень кстати.Эта статья познакомит вас с порядком процесса разработки.cookies,sessionтак же какtokenпреимущества и недостатки.

Знания этой статьи:

  1. cookie,session,token(json web token,jwt)разница
  2. nodeсерединаjwtПриложения

текст

Мы стоим на стороне сервера, как по запросу пользователя судить о том, авторизован ли он?

После проверки имени пользователя и пароля мы можем отправить клиенту учетные данные (isLogin = true), если в запросе есть эти учетные данные, то он является вошедшим пользователем.cookieа такжеsessionРазница в том, где хранятся учетные данные. Другими словами, если учетные данные хранятся на стороне клиента, то естьcookie. Если учетные данные хранятся на стороне сервера, то естьsession.

Хранилище клиента (куки)

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

Рисунок 1 Губка Боб запрашивает вызов интерфейса `/login` и отправляет учетные данные для входа `isLogin=true` Губке Бобу после прохождения проверки

Но проблема в этом:

Пользователь сам может изменитьdocument.cookie="isLogin = true"Поддельные учетные данные для входа:

Рис. 2. Губка Боб Квадратные Штаны напрямую изменяет файл cookie, чтобы пропустить проверку интерфейса входа в систему для получения данных.

Хранилище на стороне сервера (сеанс)

sessionПервоначальное значение относится к состоянию сеанса между клиентом и сервером.Поскольку учетные данные хранятся на сервере, информация, хранящаяся на сервере, также вызывается позже.session.

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

Рисунок 3. Губка Боб запрашивает вызов интерфейса `/login` и отправляет `sessionID` Губке Бобу Квадратные Штаны после прохождения проверки

Так что, даже если Губка Боб изменитsessionID, соответствующей записи в Paidaxing нет, и данные получить невозможно.

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

Token

Есть ли другой способ получить статус входа?

cookieМетод не требует серверного хранилища, но сертификат легко подделать, так как же определить, подделан ли сертификат?

а такжеHTTPSТочно так же мы можем использовать подписи, чтобы помочь серверу проверить учетные данные.

JSON Web Token（简称JWT）даJSONформат для хранения информацииToken, структура его следующая:

Рис. 4 Структурная схема JSON Web Token

JWTСостоит из 3 частей: заголовка, полезной нагрузки и подписи.

согласно сВведение на официальном сайте:

  1. хранилище заголовковTokenТип и алгоритм подписи (на рисунке выше типjwt, алгоритм шифрованияHS256)
  2. нагрузкаTokenСохраняемая информация (на приведенном выше рисунке хранится информация об имени пользователя и псевдониме)
  3. Подпись получается путем шифрования экранированного заголовка и полезной нагрузки вместе с ключом по заданному алгоритму.

Наконец, эти три части используются.подключение номера, вы можете получитьToken.

использоватьJWTСохраняя состояние входа, серверу больше не нужно поддерживать таблицу состояний, он только отправляет зашифрованные данные клиенту.token, присылайте эти зашифрованные данные с каждым запросом, а затем расшифровывайте, чтобы проверить, законны ли они. Поскольку это зашифрованные данные, даже если пользователь может их изменить, вероятность попадания очень мала.

Как клиент хранитtokenШерстяная ткань?

  1. существуетcookie, хотя установкаHttpOnlyможет эффективно предотвратитьXSSпод атакойtokenОн украден, но это означает, что клиент не может его получитьtokenустанавливатьCORSголова.
  2. существуетsessionStorageилиlocalStorage, вы можете установить заголовок, чтобы решить проблему междоменного совместного использования ресурсов, а также предотвратитьCSRF, но надо учитыватьXSSПроблема предотвращения раскрытия учетных данных.

NodeсерединаJWTиспользование

существуетNodeиспользуется вJWTТребуется всего два шага:

Первый шаг, в вашем/loginиспользуется в маршрутизацииjsonwebtokenСреднийгенерироватьtoken:

const jwt = require('jsonwebtoken')
let token = jwt.sign({
      name: user name
    }, config.secret, {
      expiresIn: '24h'
    })
    res.cookie('token', token)

Пожалуйста, обратитесь к конкретному использованиюjsonwebtokenизGithub

Второй шаг, вNodeвходной файлapp.jsзарегистрирован вexpress-jwtпромежуточное ПО дляпроверятьtoken:

const expressJwt = require('express-jwt')
app.use(expressJwt({
  secret: config.secret,
  getToken: (req) => {
    return req.cookies.token || null
  }
}).unless({
  path: [
    '/login'
  ]
}))

еслиgetTokenвернутьnull, промежуточное ПО выдастUnauthorizedErrorаномальный:

app.use(function (err, req, res, next) {
  //当token验证失败时会抛出如下错误
  if (err.name === 'UnauthorizedError') {   
      res.status(401).json({
        status: 'fail',
        message: '身份校验过期，请重新登陆'
      });
  }
});

Конкретная ссылка на грамматикуexpress-jwtизGithub

Как реализовать единый вход

Предположим, мы используем одного и того же пользователя для входа в систему и на компьютере, и на мобильном телефоне.Для сервера сгенерированы два входаtokenОба являются законными, даже если они являются одним и тем же пользователем. так что дваtokenне подведет.

Для достижения единого входа серверу нужно только поддерживатьuserIdа такжеtokenТаблица сопоставления отношений между. Обновлять каждый раз, когда вы успешно входите в системуtokenценность .

Перед обработкой бизнес-логики используйте расшифровку, чтобы получитьuserIdперейдите к таблице сопоставления, чтобы найтиtoken, а в запросеtokenСравнение может проверить, является ли это законным или нет.

Рис. 5. Реализация единого входа

Суммировать

Реализация состояния входа в систему — один из самых основных и важных навыков пользовательского интерфейса. Когда я изучал это раньше, я не мог отличитьCookie,Sessionа такжеTokenразница.sessionчемcookieЛучшее решение.tokenСтаньте основным, потому что не требует дополнительного управления хранилищем. Но когда дело доходит до единого входа, на самом деле возникает проблема, заключающаяся в том, что несколько серверов должны синхронизировать таблицу сопоставления.

Добро пожаловать, чтобы обсудить и исправить в области комментариев!

Ссылаться на

  1. Парк Линг. «Углубленное объяснение nodejs». P181
  2. горы.jwt практика и сравнение с сессией
Категории