负载均衡、Spring Security、ConcurrentSessionFilter [英] Load Balancing, Spring Security, ConcurrentSessionFilter

问题描述

我有一个 Spring 2.5.6/Flex 应用程序设置并运行 Spring Security 2.0.4.最近一个负载均衡器(A Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html) 已经到位，现在我遇到了跨域错误.基本上，负载平衡器向 myloadbalancer.abc.com 发出请求，而 myrealserver1.abc.com 作为域名返回.Spring Security 以某种方式将请求转发到真实服务器.我该如何解决这个问题?

I have a Spring 2.5.6/Flex application setup and running with Spring Security 2.0.4. Recently a load balancer (A Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html) was put into place and now I am getting cross domain errors. Basically the load balancer is firing off a request to myloadbalancer.abc.com and myrealserver1.abc.com is being returned as the domain name. Spring security is forwarding the request to the real server somehow. How can I get around this?

ConcurrentSessionFilter 也不再工作.应用程序设置为禁用并发登录，但在应用程序置于负载平衡器之后后，此功能停止.我相信也有多个 Oracle 应用服务器集群在一起.我以前从未处理过集群或负载平衡器，我不知道软件在某些方面必须以不同的方式编写.

Also the ConcurrentSessionFilter is no longer working. The application is set up to disable concurrent logons, but this functionality stopped after the application was put behind the load balancer. I believe there are multiple Oracle Application Servers being clustered together as well. I have never dealt with clustering or load balancers before and I wasn't aware that the software had to be written differently in certain areas.

这些对我来说听起来像是不同的问题，但我需要这两方面的帮助.

These sound like separate issues to me, but I need help for both.

推荐答案

关于你的第二个问题:

如果 ConcurrentSessionFilter 停止工作(即不再阻止并发会话)，这可能是由于具有粘性会话的集群应用程序容器所致.

If the ConcurrentSessionFilter stopped working (i.e. does not prevent concurrent sessions anymore), that could be due to clustered application containers with sticky sessions.

在这样的设置中，集群的每个节点独立工作，不与其他节点共享状态.相反，负载平衡器确保现有会话始终由同一节点提供服务.

In such a setup, each of the cluster's nodes works independently and doesn't share state with other nodes. Instead, the load balancer makes sure that existing sessions will always be served by the same node.

现在 Spring Security 的 ConcurrentSessionController 通过将会话映射到主体来工作.控制器本身依赖于 HttpSessionEventPublisher 在用户会话开始和终止时发送 ApplicationEvents.

Now Spring Security's ConcurrentSessionController works by mapping sessions to principals. The controller itself relies on the HttpSessionEventPublisher sending ApplicationEvents on start and termination of user sessions.

如果有人打算打开一个以上的会话最终在他已经打开一个会话的同一个节点上，一切都会正常工作.HttpSessionEventPublisher 通知并发会话机制会话的创建和身份验证将失败，因为已经有一个与此用户关联的会话.然而，在另一个节点上，该用户还没有会话，因此 ConcurrentSessionController 不会抱怨并且登录成功.

Everything is will work fine if someone intending to open more than one session ends up on the same node he already has a session opened. HttpSessionEventPublisher informs the concurrent session mechanism of the session's creation and authentication will fail because there is already a session associated with this user. On a different node however, there is no session for that user yet, so ConcurrentSessionController does not complain and login succeeds.

幸运的是，解决问题应该很容易:实现您自己的 SessionRegistry 并为所有节点(例如应用程序的数据库)使用共享数据存储.

Fortunately, solving the problem should be easy: Implement your own SessionRegistry and use a shared data store for all nodes (e.g. the application's database).

这篇关于负载均衡、Spring Security、ConcurrentSessionFilter的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！