Где хранится JSESSIONID? (JavaEE)

Question

У меня есть два приложения - веб-приложение Java EE и апплет Java SE. Я хочу аутентифицировать пользователя в апплете с помощью JSESSIONID (который создается веб-приложением).

Итак, есть проблема - как связать этот JSESSIONID с конкретным пользователем?

Как проверить (на стороне сервера веб-сервера), какой пользователь представлен таким JSESSIONID? В апплете я буду читать его из файла cookie, а затем я хочу написать простой сервлет, который примет этот JSESSIONID как сообщение POST. После этого я бы вообще ничего не написал в ответе, когда JSESSIONID плох, и информация о пользователе, если JSESSIONID хороша (т. Е. Представляет кого-то).

Кто-нибудь знает, как это сделать?

Answer 1

JSESSIONID - механизм низкого уровня, который вам, как правило, не нужно заботиться. На стороне сервера контейнер сервлета прозрачно переводит JSESSIONID в объект HttpSession, доступный в сервлете. Идентификатор сеанса также прозрачно передается на сервер с использованием заголовка Cookie или перезаписи URL.

Так что если вы нажимаете на ссылку или публикуете обычную форму на веб-странице, браузер автоматически передает JSESSIONID файл cookie или прикрепляет его к URL-адресу.

Ваша конструкция имеет существенный недостаток: безопасные контейнеры сервлет должны добавить HttpOnly атрибут JSESSIONID печенья (см: How do you configure HttpOnly cookies in tomcat/java webapps?) Это предотвращает JavaScript от чтения JSESSIONID печенья по соображениям безопасности - как пользователь угона сессия. Ваш апплет может даже не видеть этот файл cookie!

Я не знаю много о applet, но я бы посоветовал вам выполнять HTTP-запрос через веб-браузер так или иначе, чтобы идентификация безопасности (cookie) обрабатывалась автоматически.

Answer 2

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

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

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

Если идентификатор сеанса недействителен, контейнер не будет связывать объект сеанса с запросом.

Одной из последних вещей, на которые следует обратить внимание, является HttpOnly cookies. Контейнеры должны использовать их по умолчанию для идентификаторов сеанса (для защиты от атак XSS). Чтобы идентификатор сеанса был доступен для апплета, вам необходимо отключить защиту HttpOnly для файлов cookie сеанса. Это означает, что если у приложения есть уязвимость XSS, злоумышленнику будет легко украсть cookie сеанса пользователя.