没有 Cookie 和 URL 重写的会话处理答案

【问题标题】：Session Handling without Cookies and URL rewriting没有 Cookie 和 URL 重写的会话处理
【发布时间】：2011-11-25 13:26:59
【问题描述】：

我有一个旧网站（servlet、JSP 和 Struts）。目前，会话管理使用 cookie 处理。我想重新设计这个网站以使浏览器独立。

我知道有另一种方法 - URL 重写，但是，我无法重写（编码）我的应用程序中的所有 URL。

我正在寻找一种不会对我的代码产生太大影响的解决方案。如果有人有可行的解决方案，请建议我。这对我有很大的帮助。

【问题讨论】：

@SérgioMichels：这是由 cookie 支持的（另请参阅 stackoverflow.com/questions/3106452/…）。他显然想完全禁用它。 URL 重写是 cookie 的唯一替代方法，但 OP 显然出于某些不明显的原因不想使用它。也许这很耗时，但重新发明 HttpSession 需要更多时间......

标签： java jsp url-rewriting session-cookies session-management

【解决方案1】：

在我看来，仅针对浏览器独立性进行优化（不包括通过 GET 的隐式会话）时，cookie 已经是最佳解决方案。

用 javascript 重写所有 a.href 以添加会话哈希作为参数。

如果您追求真正的浏览器独立性，这不应该是您的解决方案，因为 cookie 比 javascript 支持更广泛。更大的数据块可以存储在 LocalStorage 中。

sessionStorage.setItem("key", "value");

和

var key_value = sessionStorage.getItem("key");

对于较大的客户端会话数据，设置简单且速度相当快。但是您仍然需要通过 POST/GET AJAX 调用向服务器发送一些数据，以实际跟踪服务器端的会话。

Cookie 应该是朋友，而不是敌人。

【讨论】：

【解决方案2】：

这毫无意义。只需使用 URL 重写。否则，您基本上最终会重新发明整个HttpSession 概念。您需要更改代码中使用HttpSession 的每一行。这将比修复您的 web 应用程序以利用 URL 重写需要更多的时间。咬紧牙关，将其作为经验教训，这样您就不会犯同样的错误，即不为未来需要支持不支持 cookie 的浏览器的项目进行 URL 重写。

【讨论】：

【解决方案3】：

据我所知，除了 URL 或 Cookie 中的会话令牌之外，只有三分之一的选项如此肮脏和不切实际，我不会推荐它；）但是我们开始吧：

在带有会话令牌的每个页面上都有一个隐藏的表单字段，并且对服务器的每个请求都必须是包含隐藏字段值的表单提交。

【讨论】：

我假设具体会话然后存储在应用程序范围内的某个地图中？并且不要忘记更改普通的 GET 链接以包含会话令牌。毕竟，通过这种方式，您基本上是在重新发明整个 HttpSession 和 URL 重写。