Tomcat 会话管理 - url 重写以及从 http 切换到 https
我是 C 语言的老手，但 Java/Tomcat 的新手。
我对单独使用 http 进行 Tomcat 会话管理很满意。当我开始考虑切换到 https 时，我遇到了问题。
我对 Tomcat 的了解是，如果您想在从 http 切换到 https 并返回到 http 时保持会话，则必须从 http 会话开始。当浏览器启用 cookie 时，这对我来说效果很好。
但是，当浏览器禁用 cookie（并且正在使用 URL 重写）时，将 http 切换为 https 或再次切换回 https 会导致每次启动新的会话。我假设这是一个安全问题。
Q1 - 是否可以/需要使用 URL 重写来维持 http 和 https 之间的会话？
Q2 - 如果不可能，那么电子商务开发人员如何处理非 cookie 用户？
我不想阻止非 cookie 用户使用我的网站。我确实想要在 http 和 https 之间灵活切换。
感谢您的帮助， 史蒂文.
I'm an old hand at C but a raw newbie at Java/Tomcat.
I'm fine with Tomcat session management in http alone. Its when I've come to look at switching to https that I've had problems.
I gather for Tomcat that you have to start with an http session if you want to maintain a session as you switch from http to https and back to http. This works fine for me when the browser is enabled for cookies.
But when the browser is disabled for cookies (and URL rewriting is being used) then switching http to https or back again causes a fresh session to be started each time. I'm assuming this is a security thing.
Q1 - Is it possible/desirable to maintain a session between http and https using URL rewriting?
Q2 - If it isnt possible then what do e-commerce developers do about non-cookie users?
I dont want to prevent non-cookie people using my site. I do want some flexibility switching between http and https.
thanks for any help,
Steven.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用相同的 cookie 或 URL 令牌来维护 HTTP 和 HTTPS 之间的会话似乎并不可取。
想象一下这样的情况：您的用户已登录，并且为电子商务网站中的每个请求/响应来回传递给定的 cookie（或 URL 令牌）。如果中间有人能够读取该 cookie，他就可以使用它登录到该网站的 HTTP 或 HTTPS 变体。即使合法用户正在通过 HTTPS 执行任何操作，攻击者仍然能够访问该会话（因为他也将拥有合法的 cookie）。他可以看到购物车、付款方式等页面，也许还可以更改送货地址。
在 HTTP 会话和 HTTPS 会话之间传递某种形式的令牌（如果您使用会话）是有意义的，但将它们视为同一个会导致一些漏洞。在查询参数中创建一次性标记（只是转换）可能是一种解决方案。但是，您应该将它们视为两个单独的经过身份验证的会话。
有时，使用混合 HTTP 和 HTTPS 内容的网站可能会出现此漏洞（发生这种情况时，某些浏览器（例如 Firefox）会向您发出警告，尽管大多数人倾向于在第一次弹出时将其禁用）。您可以在主页上使用 HTTPS 会话 cookie，但该页面通过普通 HTTP 包含公司徽标的图像。不幸的是，浏览器会发送两者的 cookie（因此攻击者将能够获得 cookie）。我见过这种情况发生，即使有问题的图像根本不存在（浏览器会将带有 cookie 的请求发送到服务器，即使它返回 404 未找到）。
It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.
Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.
It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.
This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).