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

Ответ 1

Это, по-видимому, поддерживается с помощью настройки конфигурации в 6.0.27 и далее:

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

< контекст sessionCookiePath = "/что-то" sessionCookieDomain = ". domain.tld" / >

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

Ответ 2

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

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

Клапаны в tomcat также являются решением проблемы из-за ограничений на доступ к заголовкам и файлам cookie, встроенным в спецификацию Servlet. Они также терпят неудачу, если 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". В качестве бонуса это решение не страдает от двойной проблемы с файлами JSESSION для клапанов.

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

configureSessionCookie(Cookie cookie)

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

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

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