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

Question

По умолчанию tomcat создаст файл cookie сеанса для текущего домена.

Если вы находитесь на www.example.com, ваш файл cookie будет создан для www.example.com (будет работать только на www.example.com). Принимая во внимание, что для example.com он будет создан для .example.com (желаемое поведение, будет работать на любом поддомене example.com, а также на самом example.com).

Я видел несколько клапанов Tomcat, которые, по-видимому, перехватывают создание сеансовых cookie-файлов и создают замещающий cookie-файл с правильным доменом .example.com, однако ни один из них, похоже, не работает безупречно, и все они, похоже, покидают существующий cookie и просто создайте новый. Это означает, что два куки-файла JSESSIONID отправляются с каждым запросом.

Мне было интересно, есть ли у кого-нибудь окончательное решение этой проблемы.

Answer 1

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

Конфигурация выполняется путем редактирования META-INF / context.xml

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

Answer 2

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

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)[^;,]*?)*)(,|$)" "$1$2; Domain=.example.com$4$5"

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

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

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

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

Answer 3

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

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

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

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

Answer 4

Техника клапанов не кажется идеальной на 100%. Если вы решитесь изменить сам Tomcat:

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

В запросе есть метод:

configureSessionCookie(Cookie cookie)

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

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

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

Answer 5

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

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

Решающим способом решения этой проблемы является отправка патча разработчикам tomcat, который добавляет настраиваемые параметры в класс SessionManager.