Лучший способ разрешить файлы cookie сеанса поддомена с помощью Tomcat

Я столкнулся с этим в $ DAYJOB. В моем случае я хотел реализовать вход в систему SSL, а затем перенаправить на страницу без SSL. Основная проблема в tomcat - это метод (из памяти) SessionManager.configureSessionCookie, который жестко кодирует все переменные, к которым вы хотите получить доступ.

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

Окончательный способ решить эту проблему - отправить разработчикам tomcat исправление, которое добавляет настраиваемые параметры к классу SessionManager.

Поскольку сеанс (и его идентификатор) в основном считается ценным только для выпускающего приложения, вы можете поискать установку дополнительного файла cookie. Взгляните на Tomcats SingleSignOnValve, предоставляющий дополнительный файл cookie JSESSIONIDSSO (обратите внимание на ... SSO) для пути к серверу «/» вместо «/ applicationName» (как обычно устанавливаются файлы cookie JSESSIONID).

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

Другая причина, по которой вы не можете использовать cookie сеанса tomcats в своих целях, заключается в том, что несколько веб-приложений на одном хосте имеют разные идентификаторы сеанса. Например. существуют разные файлы cookie для "/ webapp1" и "/ webapp2". Если вы предоставите файл cookie «/ webapp1» в «/ webapp2», он не найдет сеанс, на который вы ссылаетесь, аннулирует ваш сеанс + cookie и установит свой новый. Вам придется переписать всю обработку сеанса tomcats, чтобы принимать значения внешнего идентификатора сеанса (плохая идея с точки зрения безопасности) или разделять определенное состояние между приложениями.

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

Клапанные методы не кажутся идеальными на 100%. Если вы осмелитесь изменить сам Tomcat:

catalina.jar содержит следующий класс: org.apache.catalina.connector.Request

Запрос имеет метод:

configureSessionCookie(Cookie cookie)

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

cookie.setDomain(".xyz.com");

Кажется, работает отлично. Было бы неплохо, если бы это можно было настроить в tomcat.

Я только что прошел через все это в поисках простого решения. Сначала я начал смотреть на это с точки зрения кота.

Tomcat не дает прямого доступа к настройке файла cookie домена для сеанса, и я определенно не хотел настраивать tomcat для исправления этой проблемы, как показано в некоторых других сообщениях.

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

Поскольку мы проксируем наши запросы через Apache, я затем перешел к тому, как использовать apache для решения проблемы.

Сначала я попробовал использовать директиву mod_proxy ProxyPassReverseCookieDomain, но она не работает для файлов cookie JSESSIONID, потому что tomcat не устанавливает атрибут домена, а ProxyPassReverseCookieDomain не может работать без какого-либо домена, являющегося частью файла cookie.

Я также наткнулся на взлом с использованием ProxyPassReverseCookiePath, где они переписывали путь, чтобы добавить атрибут домена в файл cookie, но это выглядело запутанным для производственного сайта.

Я наконец заставил его работать, переписав заголовки ответов с помощью модуля mod_headers в apache, как упоминалось выше Дейвом.

Я добавил следующую строку в определение виртуального хоста:

Header edit Set-Cookie "(JSESSIONID\s?=[^;,]+?)((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(;\s?(?:(?i)Domain\s?=)[^;,]+?)?((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(,|$)" "; Domain=.example.com"

Все вышеперечисленное должно быть одной строкой в ​​файле config. Он заменит любой атрибут домена файлов cookie JSESSIONID на ".example.com". Если файл cookie JSESSIONID не содержит атрибута домена, то шаблон добавит его со значением ".example.com". В качестве бонуса это решение не страдает от проблемы двойных файлов cookie JSESSION клапанов.

Шаблон должен работать с несколькими файлами cookie в заголовке Set-Cookie, не затрагивая другие файлы cookie в заголовке. Он также должен быть модифицирован для работы с другими файлами cookie, изменив JSESSIONID в первой части шаблона на любое желаемое имя файла cookie.

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

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

Очевидно, это поддерживается настройкой конфигурации в 6.0.27 и новее:

Configuration is done by editing META-INF/context.xml

<Context sessionCookiePath = "/something" sessionCookieDomain = ".domain.tld" />

https://issues.apache.org/bugzilla/show_bug.cgi?id=48379