Репликация сеанса кластера jboss не работает (несколько cookie jsessionid)

Question

Я пытаюсь выполнить аутентификацию на своем веб-приложении, развернутом на jboss, работающем в режиме кластера с двумя узлами.

После успешной аутентификации я получаю перенаправлен на страницу администратора, где а фильтр проверяет, если я авторизован.

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

Использование инструментов разработчика я вижу Есть 3 JSessionID печенья набора: один для /, один для /myapplication пути и еще один под названием JSESSIONID-34234 также для /myapplication пути (я отдал все их перед началом процесса).

Просмотр документов jboss Я не вижу никаких объяснений, хотя это кажется источником моей проблемы.

Как я могу получить работу с проверкой подлинности (я использую аутентификацию на основе http-основы весной) в моем кластере JBoss?

Answer 1

решаемые позволяя липкой сессии, добавив следующую строку в файл конфигурации VirtualHost:

Header add Set-Cookie "ROUTEID=.%{BALANCER_WORKER_ROUTE}e; path=/myapplication" env=BALANCER_ROUTE_CHANGED 
<Proxy balancer://jboss6-hc-001-8109> 
    BalancerMember ajp://jboss2.imatiasl.lan:8109 route=jboss2-hc-001-server-02 
    BalancerMember ajp://jboss3.imatiasl.lan:8109 route=jboss3-hc-001-server-02 
    ProxySet lbmethod=byrequests stickysession=ROUTEID 
</Proxy> 

Answer 2

Веб-сессия кластеризация должна работать, если:

1. Вы позволили <distributed/> в web.xml.
2. группа серверов вашего приложение использует ha или full-ha профиль

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

В некоторых веб-папках достаточно не запрашивать повторную аутентификацию в случае отказа или сеанса, очень легко перестроить, если доступна информация аутентификации. В таких случаях вам даже не нужна кластеризация веб-сеансов. Clustered SSO достаточно, оговорка заключается в том, что вам придется использовать защиту на уровне контейнера для проверки подлинности (скорее всего, это поддерживается функцией Spring-security). Таким образом, реплицируется только информация аутентификации, поэтому вам придется разрабатывать управление данными сеанса, чтобы быть устойчивым к ситуациям, когда сеанс внезапно становится пустым.