it-roy-ru.com

Если REST приложения должны быть без сохранения состояния, как вы управляете сессиями?

Я нуждаюсь в некотором уточнении. Я читал о REST и создании приложений RESTful. Согласно википедии, само REST определено как Передача репрезентативного состояния. Поэтому я не понимаю всего этого безгражданства gobbledeygook, которое все продолжают извергать.

Из википедии:

В любой конкретный момент клиент может переходить между заявка состояния или "в состоянии покоя". Клиент в состоянии покоя может взаимодействовать с его пользователем, но не создает нагрузки и не потребляет от клиента хранение на множестве серверов или в сети.

Они просто говорят, что не используют хранилище данных на уровне сеанса/приложения ??? 

Я понял, что одна из целей REST состоит в том, чтобы сделать доступ к URI согласованным и доступным, например, вместо того, чтобы скрывать запросы подкачки внутри сообщений, делая номер страницы запроса частью URI GET. Имеет смысл для меня. Но кажется, что это просто зашкаливает, говоря, что нет для данных клиента (данные сеанса) должны когда-либо храниться на стороне сервера.

Что если бы у меня была очередь сообщений, и мой пользователь хотел прочитать сообщения, но, читая их, хотел заблокировать поступающие сообщения определенных отправителей на время его сеанса? Разве не имеет смысла хранить это в месте на стороне сервера, и сервер должен только отправлять сообщения (или идентификаторы сообщений), которые не были заблокированы пользователем?

Нужно ли отправлять полный список отправителей сообщений каждый раз, когда я запрашиваю новый список сообщений? Список сообщений, относящихся ко мне, не будет/даже не должен быть общедоступным ресурсом. 

Опять же, просто пытаюсь понять это. Кто-то пожалуйста уточнить. 


Обновление:

Я нашел вопрос о переполнении стека, ответ на который мне не совсем понятен: Как управлять состоянием в REST , В котором говорится, что состояние клиента важно должно быть все должно передаваться при каждом запросе .... Ugg .. похоже, много накладных расходов ... Это правильно ??

457
Zak

Основное объяснение:

Нет состояния сеанса клиента на сервере.

Без сохранения состояния это означает, что server не хранит никакого состояния о сеансе client на стороне сервера. 

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

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

Состояние приложения client никогда не должно храниться на сервере, а передаваться из client во все места, где это необходимо. 

Отсюда ST в REST, State Transfer. Вы передаете состояние вместо того, чтобы сервер сохранял его. Это единственный способ масштабирования до миллионов одновременно работающих пользователей. Если не по какой-либо другой причине, кроме как потому, что миллионы сеансов - это миллионы сеансов.

Нагрузка на управление сеансом амортизируется для всех клиентов, клиенты сохраняют свое состояние сеанса, и серверы могут обслуживать многие заказы или более клиентов без сохранения состояния.

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

Stateless - это то, как протокол HTTP и сеть в целом были разработаны для работы, и это в целом более простая реализация, и у вас есть один путь к коду вместо набора логики на стороне сервера для поддержки группы состояний сеанса.

Есть несколько очень простых принципов реализации:

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

Таким образом, пять ключевых принципов :

  1. Дайте каждой «вещи» удостоверение личности 
  2. Связать вещи вместе 
  3. Используйте стандартные методы
  4. Ресурсы с несколькими представлениями 
  5. Общаться без гражданства

В REST диссертация нет ничего об аутентификации или авторизации.

Потому что ничто не отличается от аутентификации запроса, который является RESTful, от запроса, который не является. Аутентификация не имеет отношения к обсуждению RESTful.

Объяснение того, как создать приложение без сохранения состояния для ваших конкретных требований, является слишком широким для StackOverflow.

Реализация Аутентификации и Авторизации в том, что касается REST, тем более слишком широка, а различные подходы к реализации подробно описаны в Интернете в целом.

Комментарии с просьбой о помощи/информации по этому завещанию/должны быть помечены как Больше не нужно.

464
user177800

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

На самом деле существует два вида государства. Состояние приложения, которое живет на клиенте, и состояние ресурса, которое живет на сервере.

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

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

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

241
Srikar Doddi

Они просто говорят, что не используют хранилище данных на уровне сеанса/приложения ???

Нет, они не говорят это тривиальным образом.

Они говорят, что не определяют «сессию». Не входите Не выходите из системы. Предоставьте учетные данные вместе с запросом. Каждый запрос стоит отдельно.

У вас все еще есть хранилища данных. У вас все еще есть аутентификация и авторизация. Вы просто не тратите время на установление сеансов и поддержание состояния сеанса. 

Дело в том, что каждый запрос (а) стоит совершенно один и (б) может быть тривиально перенесен на гигантскую параллельную ферму серверов без какой-либо реальной работы. Apache или Squid могут передавать запросы RESTful вслепую и успешно.

Что если бы у меня была очередь сообщений, и мой пользователь хотел прочитать сообщения, но, читая их, хотел заблокировать поступающие сообщения определенных отправителей на время его сеанса?

Если пользователь хочет фильтр, просто укажите фильтр для каждого запроса.

Разве не имеет смысла ... сервер отправлять только те сообщения (или идентификаторы сообщений), которые не были заблокированы пользователем?

Да. Укажите фильтр в запросе RESTful URI.

Нужно ли отправлять полный список отправителей сообщений каждый раз, когда я запрашиваю новый список сообщений? 

Да. Насколько большим может быть этот «список отправителей сообщений для блокировки»? Краткий список ПК? 

Запрос GET может быть очень большим. При необходимости вы можете попробовать запрос POST, даже если он звучит как запрос.

73
S.Lott

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

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

Это компромисс.

33
Darrel Miller

Исторический обзор управления состоянием пользовательских приложений

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

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

HTML5 и XML Header Request со временем стандартизировали понятие хранения сложных данных, включая состояние приложения стандартным способом на стороне клиента (т.е. браузера), не прибегая к переходу назад и вперед между сервером.

Общее использование REST сервисов

Службы REST обычно вызываются, когда есть транзакция, которая должна быть выполнена, или если ей нужно получить данные.

Службы REST предназначены для вызова клиентским приложением, а не конечным пользователем напрямую.

Проверка подлинности

Для любого запроса к серверу часть запроса должна содержать токен авторизации. Как это реализовано, зависит от конкретного приложения, но в целом это форма аутентификации BASIC или CERTIFICATE.

Проверка подлинности на основе форм не используется службами REST. Однако, как отмечено выше, службы REST предназначены не для вызова пользователем, а для приложения. Приложение должно управлять получением токена аутентификации. В моем случае я использовал куки с JASPIC с OAuth 2.0 для подключения к Google для аутентификации и простой HTTP-аутентификацией для автоматического тестирования. Я также использовал аутентификацию заголовка HTTP через JASPIC также для локального тестирования (хотя такой же подход может быть выполнен в SiteMinder)

Согласно этим примерам, аутентификация управляется на стороне клиента (хотя SiteMinder или Google сохраняют сеанс аутентификации на их конце), с этим состоянием ничего нельзя поделать, но оно не является частью REST сервисное приложение.

Поисковые запросы

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

Сценарии транзакций

Как отмечено выше, клиентское приложение само вызывает службы REST вместе с аутентификацией, которой оно также управляет на стороне клиента.

Для сервисов REST [если все сделано правильно] это означает, что один запрос к серверу REST будет содержать все, что нужно для однопользовательской операции, которая выполняет все, что нужно в одной транзакции , Сценарий транзакции это то, что шаблон называется.

Обычно это делается с помощью запроса POST, но можно использовать и другие, такие как PUT.

Многие надуманные примеры REST (я сам это делал) пытались следовать как можно большему количеству того, что было определено в протоколе HTTP, после того как я решил стать более прагматичным и оставил это для GET и POST только . Метод POST даже не должен реализовывать шаблон POST-REDIRECT-GET.

Несмотря на это, как я уже отмечал выше, клиентское приложение будет тем, которое вызывает службу, и будет вызывать запрос POST со всеми данными, когда это необходимо (не каждый раз). Это предотвращает постоянные запросы к серверу.

Голосование

Хотя REST можно использовать и для опроса, я не буду рекомендовать его, если вы не используете его из-за совместимости браузера. Для этого я бы использовал WebSockets, для которых я также разработал API-контракт . Другой альтернативой для старых браузеров является CometD.

30
Archimedes Trajano

ОТДЫХ очень абстрактный. Это помогает иметь несколько хороших, простых, реальных примеров. 

Возьмем, к примеру, все основные приложения для социальных сетей - Tumblr, Instagram, Facebook и Twitter. Все они имеют вид с непрерывной прокруткой, где чем дальше вы прокручиваете вниз, тем больше контента вы видите, все дальше и дальше назад во времени. Тем не менее, мы все пережили тот момент, когда вы теряете то, куда вы прокручивались, и приложение сбрасывает вас обратно наверх. Например, если вы выйдете из приложения, то при повторном открытии вы снова вернетесь наверх.

Причина в том, что сервер не сохранил ваше состояние сеанса. К сожалению, ваша позиция прокрутки была просто сохранена в RAM на клиенте. 

К счастью, вам не нужно повторно входить в систему при повторном подключении, но это только потому, что срок хранения вашего сертификата входа на стороне клиента также не истек. Удалите и переустановите приложение, и вам придется снова войти в систему, поскольку сервер не связал ваш IP-адрес с вашим сеансом. 

У вас нет сеанса входа на сервер, потому что они соблюдают REST.


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

Но давайте поговорим о веб-браузерах на секунду, потому что это поднимает еще одно важное преимущество REST, о котором никто здесь не говорит.

Если сервер пытался сохранить состояние сеанса, как он должен идентифицировать каждого отдельного клиента? 

Он не может использовать свой IP-адрес, потому что многие люди могут использовать этот же адрес на общем маршрутизаторе. Так как же тогда? 

Он не может использовать MAC-адрес по многим причинам, не в последнюю очередь из-за того, что вы можете войти в несколько учетных записей Facebook одновременно в разных браузерах и в приложении. Один браузер может легко выдать себя за другой, а MAC-адреса также легко подделать.

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


Итак ... Я надеюсь, что теперь вы понимаете, почему REST так важен для масштабируемости. Я надеюсь, что вы можете начать понимать, почему состояние сеанса на стороне сервера связано с масштабируемостью сервера, а наковальни - с ускорением автомобиля. 


Люди запутываются, думая, что «состояние» относится, например, к информации, хранящейся в базе данных. Нет, это относится к любой информации, которая должна быть в RAM сервера, когда вы ее используете. 

24
CommaToast

Я вижу, что основной проблемой здесь является смешивание Session with State . И хотя REST указывает, что вы НЕ должны хранить State на сервере, ничто не мешает вам сохранить пользователя Session.

Управление State на сервере означает, что ваш сервер точно знает, что делает клиент (какую страницу они просматривают в каком разделе приложения). И это то, что вам не нужно делать.

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

Кто-то может поспорить, что клиент должен лучше генерировать токен. Я говорю, что это работает в обоих направлениях, и это будет зависеть от приложения и от того, кто будет работать с API.

Также хранение правильных данных сеанса на сервере должно быть правильным способом. Вы не можете доверять клиенту хранить его корзину покупок, которая (например) содержит поле с именем «isFreeGift». Такая информация должна храниться на сервере.

Ссылка на видео, предоставленная Santanu Dey в его ответе, полезна. Посмотрите, если нет.

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

Хотя этому вопросу уже несколько лет, я надеюсь, что мой ответ все равно будет полезен.

12
Sam Sirry

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

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

Да, протокол HTTP, по сути, является протоколом без сохранения состояния, но для придания ему состояния мы используем файлы cookie HTTP. Итак, это SOAP по умолчанию. Но это также может быть сделано с учетом состояния, в зависимости от используемой вами платформы.

HTTP не имеет состояния, но все же мы можем поддерживать сеанс в нашем приложении Java, используя другой механизм отслеживания сеансов.

Да, мы также можем поддерживать сеанс в веб-сервисе, будь то REST или SOAP. Это может быть реализовано с помощью любой сторонней библиотеки или вы можете реализовать самостоятельно.

Взято из http://gopaldas.org/webservices/soap/webservice-is-stateful-or-stateless-rest-soap

11
Ata ul Mustafa

Посмотрите на эту презентацию. 

http://youtu.be/MRxTP-rQ-S8

Согласно этому шаблону - создайте временные спокойные ресурсы для управления состоянием, если и когда это действительно необходимо. Избегайте явных сессий.

5
Santanu Dey

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

ИМО, API должен быть без сохранения состояния, что позволяет действительно быстро масштабироваться. 

3
psuhas

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

Это REST ограничение безгражданства очень важно. Без применения этого ограничения ваше серверное приложение не будет масштабироваться хорошо, потому что поддержка каждого отдельного клиентского сеанса будет его ахиллесовой пятой .

2
inf3rno

Вся концепция в другом ... Вам не нужно управлять сессиями, если вы пытаетесь реализовать протокол RESTFul. В этом случае лучше выполнять процедуру аутентификации для каждого запроса (в то время как с точки зрения производительности это требует дополнительных затрат - хэширование пароля было бы хорошим примером. Ничего страшного ...). Если вы используете сеансы - как вы можете распределить нагрузку между несколькими серверами? Бьюсь об заклад, протокол RESTFul предназначен для исключения сессий вообще - они вам на самом деле не нужны ... Вот почему он называется «без сохранения состояния». Сеансы требуются только в том случае, если вы не можете сохранить что-либо, кроме Cookie, на стороне клиента после выполнения запроса (например, старый браузер, не поддерживающий Javascript/HTML5). В случае «полнофункционального» клиента RESTFul обычно безопасно хранить base64(login:password) на стороне клиента (в памяти) до тех пор, пока приложение не будет загружено - приложение используется для доступа к единственному хосту, и cookie не может быть скомпрометирован сторонние скрипты ...

Я настоятельно рекомендую отключить проверку подлинности с помощью cookie-файлов для сервисов RESTFul ... проверьте Basic/Digest Auth - этого должно быть достаточно для сервисов на основе RESTFul.

0
user3857922

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

Приходя к управлению сессиями или предоставляя пользователям возможность настраивать взаимодействие с пользователем, требуется поддерживать некоторые метаданные или состояние вероятных пользовательских предпочтений пользователя, историю прошлых запросов. Это может быть сделано путем сохранения файлов cookie, скрытых атрибутов или объекта сеанса.

Это может поддерживать или отслеживать состояние пользователя в приложении.

Надеюсь это поможет!

0
Sourabh Bhavsar

REST не имеет состояния и не поддерживает состояния между запросами. Клиентские куки/заголовки настроены на поддержание пользовательского состояния, такого как аутентификация. Скажем, имя пользователя/пароль клиента проверяются механизмом аутентификации третьей стороны - получение OTP 2-го уровня и т.д. Как только пользователь проходит аутентификацию - заголовки/файлы cookie доходят до конечной точки службы покоя, и мы можем считать пользователя аутентифицированным, поскольку пользователь приходит с действительными заголовками/файлами cookie. , Теперь определенная информация о пользователе, например IP, либо сохраняется в кэше, и после этого, если запрос поступает с того же Ip (mac-адреса) для перечисленных ресурсов, пользователю разрешено. И кеш поддерживается некоторое время, которое становится недействительным по прошествии времени. Таким образом, можно использовать либо кэш, либо записи БД для сохранения информации в ч/б запросах.

0
Amit

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

Но то, что вы можете сделать, и что имеет реальный смысл, - это уменьшить ваш веб-сервер до минимума. Такие языки, как PHP, очень просто помещают все в хранилище сеансов; Вы можете сделать это, но если у вас много веб-серверов, они должны использовать что-то общее между ними (NFS, Redis, Memcached, что-то), чтобы ваш следующий запрос знал, что вы сделали одним кликом ранее. Это связано с балансировкой нагрузки - вы можете оказаться на другом веб-сервере со своим следующим запросом. И хотя между ними ОБЯЗАТЕЛЬНО должно быть общее хранилище (главным образом потому, что им придется сообщать, вошли вы в систему или нет), вы не должны использовать его в качестве альтернативной базы данных. Это не для этого.

То есть вы говорите, чтобы сохранить сессионное хранилище до минимума?

Опять же, это ваше решение. Вы можете хранить вещи там из соображений производительности (база данных почти всегда медленнее, чем Redis), вы можете хранить информацию избыточно, реализовывать собственное кэширование, что угодно - просто имейте в виду, что веб-серверы будут иметь большую нагрузку, если вы будете хранить много мусора на них. Кроме того, если они сломаются под большими нагрузками (и они будут), вы потеряете ценную информацию; с помощью мышления REST все, что происходит в этом случае, это то, что клиент снова отправляет тот же (!) запрос, и на этот раз он обслуживается.

Как это сделать прямо тогда?

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

Думайте и решайте, не позволяйте тенденциям дизайна думать за вас.

0
dkellner

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

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

Если RESTful API ожидает имя пользователя и пароль для изменения имени пользователя и пароля, то даже если кто-то выдал себя за пользователя, используя идентификатор сеанса, хакер не сможет заблокировать реального пользователя.

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

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

0
Lajos Arpad