我有一个在 Tomcat 6.0.29 上运行的 Java 应用程序，前面是 Apache 2.2.3。登录页面使用 HTTPS，而大多数页面使用 HTTP。
如果用户尝试访问受登录保护的页面 (HTTP)，他会被重定向到登录页面 (HTTPS)，登录，然后被重定向回最初请求的页面。这很好用，因为 JSESSIONID cookie 设置为不安全的，并且用于 HTTP 和 HTTPS。
但是，如果用户从登录页面 (HTTPS) 开始，则 JSESSIONID cookie 设置为 Secure，因此在登录后重定向到 HTTP 下的页面时会话不可用，从而强制一个新会话并再次重定向到登录页面。不过这次它起作用了，因为这一次 JSESSIONID cookie 被设置为不安全的。
如何避免用户在第一次点击登录页面时必须登录两次？
（更新：为清楚起见）从登录 Http get/post 开始，使用 https 并在用户的登录会话中使用 https。
仅在没有登录用户时使用 Http。
cookie 不允许跨越协议边界是有原因的——它是一种攻击媒介！（*见下面的更新）
如何做这个非常糟糕的主意
如果您真的坚持，请将重定向中的 jsessionId 编码到 http url（或始终在 url 中编码 jsession id）。当 Tomcat 获得 http 重定向时，tomcat 应该找到会话并继续。
为什么你不应该这样做
说真的，任何在同一页面上混合 https 和 http 内容的网站都会让自己面临各种有趣（和简单）的攻击。
如果会话的其余部分是明文的，那么从 https 去保持登录“安全”是没有意义的。那么用户名/密码（可能只是密码）受到什么保护？
使用流行的中间人攻击，攻击者只需复制会话 ID 并使用它来获得乐趣。由于大多数站点不会使保持活动状态的会话过期，因此 MIM 实际上拥有完全访问权限，就好像他们拥有密码一样。
如果您认为 https 在性能方面很昂贵，请看这里，或者只是搜索。将 https 性能提高到可接受的最简单方法是确保服务器在连接上设置保持活动状态。
更新 1：有关更多信息，请参阅Session Hijacking或Http Cookie Theft
更新 2：请参阅Firesheep Firefox 插件，了解如何快速轻松地完成此操作。