0

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

это из документации рамки игры: (link)

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

и

Конечно, значения cookie подписываются секретным ключом, поэтому клиент не может изменять данные cookie (или он будет признан недействительным).

Теперь мой вопрос: если сервер ничего не сохраняет о идентификаторе сеанса, как он аутентифицирует сеанс, исходящий от клиента ?!

Я много искал, но не смог узнать, как работает управление сеансом на стороне сервера.

ответ

2

Теперь мой вопрос, если сервер ничего не сохранить о идентификатор сессии, как это проверить подлинность сеанса, идущий от клиента?

Какая игра делает это, она подписывает ваши данные сеанса с помощью ключа, скажем, KEY (его приложение, которое вы устанавливаете в application.conf) и создаете буквенно-цифровые данные. Затем он присоединяет данные и зашифрованные данные кук и отправляет его обратно

зашифрованных данных =5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea

DATA =[email protected]&userName=silentprogrammer

Если вы осмотрите печенье (правая кнопка мыши на browser-> Проверить element-> Application-> Cookie-> Your url) в браузере вашего приложения вы можете увидеть что-то вроде

"[email protected]&userName=silentprogrammer" 

Для каждого запроса он получает часть данных ([email protected]&userName=silentprogrammer), которая снова знакомит данные с KEY и проверяет ее на буквенно-цифровые данные, поступающие от запроса, т.е. 5d9857e8a41f94ecb2e4e957cd3ab4f263cfbdea, если оба они равны (если данные и ключ шифрования одинаковы) сессия подтверждена иначе сеанс истекает. Вы можете подтвердить это, изменив часть данных из файла cookie в браузере и отправив запрос снова, сессия не будет существовать.

Это то, что я наблюдал

+1

Подтверждение - секретный ключ действительно определяется 'application.secret' в' application.conf'. –