JSP - 无法维护 http 页面和 https 页面之间的会话
我似乎无法找到解决我的问题的唯一正确答案。我对在互联网上找到的信息不知所措,我不知道我应该做什么。
我的设置如下: Apache服务器(前端),Tomcat 6.0(后端),RapidSSL证书位于Apache服务器上,我的网站由Java服务器组成页数。
问题:
我有几个页面位于 https 下,而其余网站页面位于 http 下。 我的登录页面位于 https 下,我注意到当我登录并重定向到 http 页面时,会话没有得到维护。它创建一个新页面,这会导致用户被发送到我的“会话过期”页面,而实际上,在成功登录后,他们将被重定向到另一个页面。
问题:
为什么从 https 切换到 http 时会话不保持?
我该如何解决这个问题? 我需要在 http 页面上创建的会话属性出现在 https 页面上,因此当用户再次定向到 http 页面时,会话尚未重新创建,属性也会丢失。
请向我提出您认为有必要的任何问题,以帮助我解决这个问题。我非常感谢我收到的任何帮助。这个问题已经成为我的绊脚石,特别是因为我显然缺乏自己解决这个问题的“专业知识”。
I can't seem to find the one right answer to my problem. I'm being overwhelmed with information I'm finding on the internet, and I have no idea what I should do.
My setup is as follows : Apache server (front end), Tomcat 6.0 (back end), RapidSSL certificate is on the Apache server, my site is made up of Java Server Pages.
The problem :
I have a few pages that are under https, while the rest of the site pages are under http.
The login page I have, is under https, and I've noticed that when I login, and redirect to an http page, that the session is not being maintained. Its creating a new one, which results in the user being sent to my 'session expired' page, when really, upon a successful login, they would be redirected to a different page.
Questions:
Why is the session not maintained when switched from https to http?
How do I fix this problem?
I need the session attributes that are created on the http pages, to be present on the https pages, so when the user is then directed to an http page again, the session hasn't been recreated, and the attributes lost.
Please ask me any questions you feel are necessary in order to help me figure this out. I greatly appreciate any help I receive. This issue has become a stumbling block for me, especially since I obviously lack the 'expertise' to figure it out myself.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
允许用户登录后使用相同的会话是一个安全漏洞。默认情况下,Tomcat 不允许会话从 SSL 迁移到非 SSL 页面。
您应该更改您的逻辑,以便如果用户正在登录,会话会以静默方式更新并登录,而不是转到会话过期页面。
Allowing the user to use the same session after logging in is a security vulnerability. Tomcat by default does not allow sessions to migrate from SSL to non SSL pages.
You should change your logic so if a user is doing a login, the session is silently updated, and logged in instead of going to the session expired page.
您可能正在使用“安全 cookie”来维护会话:这些 cookie 不会从 HTTPS 传播到 HTTP。这通常是一件好事。
您可以选择不这样做,但是当您将会话从 HTTPS 传输到 HTTP 时,您必须格外小心,不允许稍后通过 HTTPS 重用它,因为它可能已被泄露。
It's likely that you're using "secure cookies" to maintain the session: these cookies don't propagate from HTTPS to HTTP. This is generally a good thing.
You can chose not to do this, but when you transfer a session from HTTPS to HTTP you have to take extra care that you don't allow it to be reused over HTTPS later, as it may have been compromised.
您是否使用简单的反向代理连接到 Tomcat?如果您的情况如此,请使用
mod_proxy_ajp
来使用AJP
将 Apache HTTP Server 连接到 Tomcat 应用程序服务器。Are you using a simple reverse proxy to connect to Tomcat? If that's your case, use
mod_proxy_ajp
to useAJP
to connect Apache HTTP Server to Tomcat Application Server.我也有同样的问题,网站的某些部分是https,有些部分是http。我发现使用 Tomcat,通过 http 创建的会话 cookie 转移到 https 没有问题,但是在转移到 http 时,通过 https 创建的会话 cookie 会丢失。
我发现在用户访问网站时维持会话的一个解决方案是在用户第一次到达时让他们跳来跳去。我使用以下代码创建了一个 RequestFilter:
这会强制新会话使用非 SSL 创建持久会话 cookie,然后一旦会话存在,用户就会转发回安全请求。这会导致会话保持活动状态。
或者,这里有一个涉及较少跳动的选项,只需用不安全的 cookie 覆盖会话 cookie:
I have the same issue, where some parts of the site are https, and some are http. I've found that with Tomcat, session cookies created over http carry over to https no problem, however session cookies created over https are lost when moving to http.
One solution I have found maintaining a session as the user travels the site, is to bounce the user around when they first arrive. I created a RequestFilter with the following code:
This forces new sessions to non SSL to create a lasting session cookie, and then once a session exists, the user forwarded back to secure request. This results in the session staying alive.
Or here's an options that involves less bouncing around, just overwrite the session cookie with one that isn't secure: