Лучший способ разрешить куки-файлы поддомена с помощью 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

< Контекст sessionCookiePath = "/ что-то" sessionCookieDomain =/>

"domain.tld."

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

configureSessionCookie(Cookie cookie) 

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

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

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

Answer 5

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

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

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

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