脚本

>我重新启动服务器和浏览器,因此没有会​​话数据.
>我去www.someurl.com公共访问页面.我的控制器通过这个HttpSession session = request.getSession(true)给我一个会话;
>我点击飞往www.someurl.com/admin限制访问页面的飞机锚点链接,该页面将在新选项卡中打开. Spring Security 3拦截了这一点并对凭证提出了挑战.我成功登录.
>我回到www.someurl.com的上一个标签并刷新页面.

问题

我在www.someurl.com的控制器中注意到,会话ID在步骤2和步骤4中是不同的.看起来Spring Security创建了一个新会话,该会话现在附加到公共页面请求.为什么会发生这种情况,我是否可以强制Spring Security使用现有会话？

追踪的场景

>重新启动浏览器和服务器,以便不存在会话数据.
>我去www.someurl.com.控制器已注入请求. request.session为null. getSession(true)给我一个id为87B091B12F38D44C53AF0DA9E2147484的会话. LogService获取请求对象并且也执行getSession(true)但是获取了具有id 87B091B12F38D44C53AF0DA9E2147484的会话,所以到目前为止一切都很好.
>我点击/管理员.页面在新选项卡中打开.我登录
>我刷新了www.someurl.com.控制器已注入请求. request.session不为空.会话ID为547DF59035C91783D783BAEF4A15FBFF.

解决方法:

你的诊断错误了：

What I notice in my controller for www.someurl.com is that the session id is different on step 2 and step 4. Looks like Spring Security created a new session and that session is now attached to the request for public page.

这正是因为所有页面都使用相同的会话,当您返回第一个选项卡并刷新时,您仍然以管理员身份登录.给定浏览器的所有选项卡和框架共享给定webapp的相同会话.这就是它的工作原理.服务器不知道并关心浏览器选项卡.它获取附加到给定浏览器发送的所有请求的会话cookie,并使用此cookie来获取相应的会话.这实际上是件好事.如果没有它,每次打开一个已经过身份验证的新选项卡时,都必须再次进行身份验证.而你绝对不希望如此.

那么让我们解释一下你的场景中会发生什么：

>您重新启动服务器和浏览器,因此没有会​​话数据.
>您访问www.someurl.com公共访问页面.你的控制器会给你一个会话. Cookie会被发送回浏览器
>您单击飞往www.someurl.com/admin限制访问页面的飞机锚点链接,该页面将在新选项卡中打开. cookie随请求一起发送,因此该请求是在步骤2中打开的会话的一部分.Spring Security 3拦截了这个以及对凭证的挑战.它将凭据附加到会话,该会话现在是经过身份验证的会话
>您可以使用www.someurl.com返回上一个选项卡并刷新页面. cookie再次发送,Spring知道您是在步骤3中进行身份验证的人,因为身份验证凭据存储在会话中.

编辑：看来我错了,Spring确实在登录后创建了一个新会话,以防止会话固定攻击. the documentation中提供了有关其原因以及如何避免此行为的说明：

Session fixation attacks are a potential risk where it is possible for a malicious attacker to create a session by accessing a site, then persuade another user to log in with the same session (by sending them a link containing the session identifier as a parameter, for example). Spring Security protects against this automatically by creating a new session when a user logs in. If you don’t require this protection, or it conflicts with some other requirement, you can control the behaviour using the session-fixation-protection attribute on , which has three options

• migrateSession – creates a new session and copies the existing session attributes to the new session. This is the default.

• none – Don’t do anything. The original session will be retained.

• newSession – Create a new “clean” session, without copying the existing session data.