Какова цель суффикса JSESSIONID?

Question

После использования браузера для проверки подлинности в мою службу, я нахожу множество печенья со следующим ключом \ парой значений: («» то есть после того, как: e34Mc3uLa3yPbO0La3aNa3eTc38Ke0)

JSESSIONID=40d4b01c47ddb858718291d319a1a817d3037fdc6f2c341c195a94dc6ee8e8a1.e38Lb3qTb3aKai0RbxeMahqNbN90; path=/MyService; secure 

Примечания суффикса

Когда я использую API Java servetl, чтобы получить идентификатор сессии (javax.servlet.http.HttpSession.getId()), я получаю следующее значение

40d4b01c47ddb858718291d319a1a817d3037fdc6f2c341c195a94dc6ee8e8a1 

который является таким же, как первый порт я значение переменной cookie, о которой я только что упомянул!

Однажды я пытался поддерживать сеанс между несколькими HTTP-запросами на ColdFusion (CF) (его нормально, если вы не знаете, что такое CF, его просто платформа для разработки приложений), и я не мог поддерживать сеанс, если Я установил переменную cookie JSESSIONID на всю ценность, о которой я упомянул в начале этого вопроса. Для правильной работы сеанса мне пришлось отправить первую часть идентификатора сеанса (например, перед «.»)

Так что я задаю вопрос, почему API сервлета возвращает часть JSESSIONID, в то время как возвращаемое значение cookie с сервера имеет суффикс? Откуда этот суффикс com и какова его цель?

Answer 1

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

Это полезно в некластеризованных настройках, чтобы убедиться, что сеанс действительно принадлежит серверу. Представьте себе настройку балансировки нагрузки с липкими сеансами и сбоем сервера. Запросы теперь направлены на другой сервер. Теоретически этот сервер также может иметь сеанс с тем же идентификатором сеанса. Затем пользователь войдет в сеанс, который не принадлежит ему. Добавление уникального суффикса сервера позволяет серверу приложений не восстанавливать сеансы, которые не были созданы на том же сервере.

Вы можете получить представление об этом здесь: https://developer.jboss.org/message/879684, где обсуждаются различия в этом поведении между jboss 7 и wildfly 8.1.