Лучший способ для разрешения сеансовых куки субдомена с помощью Tomcat
To use buildconfig from build.gradle to Android manifest then.
android {
// For settings specific to a product flavor, configure these properties
// for each flavor in the productFlavors block.
defaultConfig {
// Creates a property for the FileProvider authority.
def filesAuthorityValue = applicationId + ".files"
// Creates a placeholder property to use in the manifest.
manifestPlaceholders =
[filesAuthority: filesAuthorityValue]
// Adds a new field for the authority to the BuildConfig class.
buildConfigField("String",
"FILES_AUTHORITY",
"\"${filesAuthorityValue}\"")
}
...
}
...
<manifest>
...
<application>
...
<provider
android:name="android.support.v4.content.FileProvider"
android:authorities="${filesAuthority}"
android:exported="false"
android:grantUriPermissions="true">
...
</provider>
</application>
</manifest>
5 ответов
Это, по-видимому, поддерживается через настройку конфигурации в 6.0.27 и далее:
Конфигурация выполняется путем редактирования META-INF/context.xml
Поскольку сессию (и ее идентификатор) в основном рассматривают значения только для issueing приложения, можно скорее искать установку дополнительного cookie. Взгляните на Котов SingleSignOnValve, предоставляя дополнительному Cookie JSESSIONIDSSO (отметьте... SSO) для пути сервера "/" вместо "/applicationName" (поскольку cookie JSESSIONID обычно устанавливаются).
С таким Клапаном можно реализовать любое межпроцессное взаимодействие, в котором Вы нуждаетесь для синхронизации любого состояния между различными серверами, виртуальными хостами или веб-приложениями на любом количестве tomcats/webservers/whatever.
Другая причина, почему Вы не можете использовать сеансовые куки котов в своих собственных целях, что несколько веб-приложений на том же хосте имеют различные идентификаторы сессии. Например, существуют различные cookie для "/webapp1" и "/webapp2". При обеспечении "/webapp1" cookie "/webapp2" это не нашло бы сессию, на которую Вы сослались, делайте недействительным свой session+cookie и установите его собственный новый. Необходимо было бы переписать всю обработку сессии котов, чтобы принять внешние значения идентификаторов сессии (плохая идея securitywise) или совместно использовать определенное состояние среди приложений.
обработку Сессии нужно считать контейнерами (коты) бизнес. Независимо от того, что Вам нужны Вы, должен добавить, не вмешиваясь в то, чему верит контейнер, необходимо, чтобы сделать.
Методы клапана, кажется, не на 100% прекрасны. Если Вы смеете изменять сам Tomcat:
catalina.jar содержит следующий класс: org.apache.catalina.connector. Запрос
Запрос имеет метод:
configureSessionCookie(Cookie cookie)
Для нашей среды было лучше просто hardcode он, но Вы могли сделать более необычную логику:
cookie.setDomain(".xyz.com");
, Кажется, работает отлично. Было бы хорошо, если бы это настраивалось у кота.
Я столкнулся с этим на уровне $DAYJOB. В моем случае я хотел реализовать вход в систему SSL, тогда перенаправляют к не странице SSL. Базовой проблемой у кота является метод (из памяти) SessionManager.configureSessionCookie, к каким твердым кодам все переменные требуется получить доступ.
я придумал несколько идей, включая особенно вопиющий взлом с помощью mod_headers в апаче для перезаписи cookie на основе regex замены.
категорический способ решить это должно было бы отправить патч к разработчикам кота, который добавляет конфигурируемые параметры к классу SessionManager.
Я только что прошел через все это в поисках простого решения. Сначала я начал смотреть на это с точки зрения tomcat.
Tomcat не дает прямого доступа к настройке доменной cookie для сессии, и я определенно не хотел ставить пользовательский патч для tomcat, чтобы решить эту проблему, как показано в некоторых других сообщениях.
Клапаны в tomcat также кажутся проблемным решением из-за ограничений на доступ к заголовкам и cookies, встроенных в спецификацию сервлетов. Они также не работают полностью, если http-ответ коммитируется до того, как он будет передан вашему клапану.
Поскольку мы проксируем наши запросы через Apache, я перешел к тому, как использовать apache для решения проблемы.
Сначала я попробовал директиву mod_proxy ProxyPassReverseCookieDomain, но она не работает для куки JSESSIONID, потому что tomcat не устанавливает атрибут домена, а ProxyPassReverseCookieDomain не может работать без домена, который является частью куки.
Я также встретил хак с использованием 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"
Все вышеперечисленное должно быть одной строкой в конфиге. Это заменит любой атрибут домена куки JSESSIONID на ".example.com". Если куки JSESSIONID не содержат атрибута домена, то шаблон добавит его со значением ".example.com". В качестве бонуса, это решение не страдает от проблемы двойных куки JSESSION в клапанах.
Шаблон должен работать с несколькими cookies в заголовке Set-Cookie, не влияя на другие cookies в заголовке. Он также должен быть модифицируемым для работы с другими куками путем изменения JSESSIONID в первой части шаблона на любое имя куки по вашему желанию.
Я не опытный пользователь reg-ex, поэтому я уверен, что есть пара оптимизаций, которые можно было бы внести в этот шаблон, но пока что он, кажется, работает для нас.
Я обновлю это сообщение, если найду какие-либо ошибки в шаблоне. Надеюсь, это избавит некоторых из вас от необходимости переживать последние пару дней разочарований, как это сделал я.