Балансировка нагрузки, Spring Security, ConcurrentSessionFilter - PullRequest
Новая
       7

Балансировка нагрузки, Spring Security, ConcurrentSessionFilter

3 голосов
/ 03 февраля 2009

У меня есть приложение Spring 2.5.6 / Flex, настроенное и работающее с Spring Security 2.0.4. Недавно был установлен балансировщик нагрузки (Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html), и теперь я получаю междоменные ошибки. В основном балансировщик нагрузки запускает запрос к myloadbalancer.abc.com и myrealserver1.abc.com возвращается как доменное имя. Spring security как-то перенаправляет запрос на реальный сервер. Как мне обойти это?

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

Для меня это звучит как отдельные проблемы, но мне нужна помощь для обоих.

1 Ответ

3 голосов
/ 15 марта 2009

По поводу вашей второй проблемы:

Если ConcurrentSessionFilter перестал работать (т.е. больше не предотвращает параллельные сеансы), это может быть связано с кластеризованными контейнерами приложений с прикрепленными сеансами.

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

Теперь ConcurrentSessionController Spring Security работает путем сопоставления сеансов с принципалами. Сам контроллер полагается на HttpSessionEventPublisher отправку ApplicationEvents при запуске и завершении пользовательских сеансов.

Все будет хорошо, если кто-то, намеревающийся открыть более одного сеанса, окажется на том же узле, у которого он уже открыл сеанс. HttpSessionEventPublisher сообщает параллельному механизму сеанса о создании сеанса, и аутентификация не удастся, потому что с этим пользователем уже связан сеанс. Однако на другом узле сеанса для этого пользователя еще нет, поэтому ConcurrentSessionController не жалуется и вход в систему завершается успешно.

К счастью, решение проблемы должно быть простым: реализовать собственный SessionRegistry и использовать общее хранилище данных для всех узлов (например, базы данных приложения).

...