Tomcat HTTPS 转向 HTTP 时, Session 丢失.

使用 Spring security, 发现有时第一次输入密码,却又返回登录页面的情况.

情景:

1.进入  https 的 login.jsp ,输入用户名密码
2.请求 https 的 j_spring_security_check , 验证用户名和密码.
3.通过校验,跳转到目标 Login Success Controller ,
4.但因为 Login Success Controller 配置为 http , 转换协议
5.在 tomcat 的原因下,又创建了一次 HTTP Session,造成保存在原 HTTPS Session内的内容丢失(用户权限信息).
6.SpringSecurity 拦截目标为  Login Success Controller 的请求,校验失败,
7.返回登录页面,
8.在输入密码,虽然又转回为 https 请求,但使用的是第二次创建的 http session
9.使用了第二次创建的 HTTP Session 一切正常.

如果有碰到类似情况的,可以参考下.


Tomcat  HTTPS Session 不支持 HTTP 请求,
会重新创建一个新的HTTP Session,并且不会复制原Session里的信息
但 HTTP Session 支持 HTTPS 的请求.


木有了其他了,沉了吧...

http://static.springsource.org/spring-security/site/faq.html

2.3.

I'm using Tomcat (or some other servlet container) and have enabled HTTPS for my login page, switching back to HTTP afterwards. It doesn't work - I just end up back at the login page after authenticating.

This happens because sessions created under HTTPS, for which the session cookie is marked as “secure”, cannot subsequently be used under HTTP. The browser will not send the cookie back to the server and any session state will be lost (including the security context information). Starting a session in HTTP first should work as the session cookie won't be marked as secure (you will also have to disable Spring Security's Session Fixation Protection support to prevent it from creating a new secure session on login (you can always create a new session yourself at a later stage). Note that switching between HTTP and HTTPS is not a good idea in general, as any application which uses HTTP at all is vulnerable to man-in-the-middle attacks. To be truly secure, the user should begin accessing your site in HTTPS and continue using it until they log out. Even clicking on an HTTPS link from a page accessed over HTTP is potentially risky. If you need more convincing, check out a tool like sslstrip.

http://name327.iteye.com/admin/blogs/1591796
请LZ看下这个。 Https到http session会话跟踪失效的解决办法

HttpServletRequest request = ServletActionContext.getRequest(); 
        HttpServletResponse response=ServletActionContext.getResponse(); 
        Cookie cookie = new Cookie("JSESSIONID", request.getSession().getId()); 
        response.addCookie(cookie); 

已经这么做了,后来同事发现,在 火狐 下有的插件可以修改 cookie 是不是安全的 cookie ,但没弄明白非安全的 cookie 和安全的 cookie 到底是哪里的区别 ,貌似是 secure 这个属性,但在服务器拿到的 cookie 也都还是false.

在深入就搞不通了.

换句话说,重建一个session的根本原因是什么没弄清楚.
可能是因为 secure 这个属性,或者是因为那个 https 端口的监听.

都是胡闹,本身https转向http导致你端口变化也就不是同域跳转,正确做法是依然调回https

安全的 cookie的cookie只能在https下使用。

LZ  回复完你帖子就关了。
刚才才看到你的回复。

发生会话跟踪丢失的根本原因是 tomcat认为是一个新的会话连接进来， 这个可以创建一个sesion监听器看效果。
火狐里面可以修改cookie的插件 这个和服务端重写jsessionid没有关系。理论上任何的session都可以伪造，服务端判断客户端的来源就是根据客户端提交到服务器的jsessionid 然后找到相应的session ，以上只是我的个人理解，如果有错误请批评指正。LZ可以在网上找找Http会话跟踪原理

呵呵,胡闹的事天天都有.

servlet2.5中不支持获取sessionid。