ColdFusion 会话与 J2EE 会话答案

【问题标题】：ColdFusion sessions vs J2EE sessionsColdFusion 会话与 J2EE 会话
【发布时间】：2012-08-07 09:45:05
【问题描述】：

ColdFusion 会话与 J2EE 会话相比有什么好处？

ColdFusion session documentation 提到了 J2EE 会话的好处，但没有提到 ColdFusion 会话的任何优点。 J2EE 会话自 ColdFusion MX（2002 年发布）以来一直可用，但仍有很多人使用标准的 ColdFusion 会话。 J2EE 会话是否存在 ColdFusion 会话不存在的任何缺点？

J2EE 会话管理与 ColdFusion 会话管理相比具有以下优势：

J2EE 会话管理使用特定于会话的会话标识符jsessionid，它是在每个会话开始时重新创建的。

您可以在 ColdFusion 页面和从 ColdFusion 页面调用的 JSP 页面或 Java servlet 之间共享会话变量。

Session 范围是可序列化的（可转换为稍后可以完全恢复为原始对象的字节序列）。使用 ColdFusion 会话管理，会话范围是不可序列化的。只有可序列化的范围可以在服务器之间共享。

因此，请考虑在以下任何情况下使用 J2EE 会话管理：

您希望最大限度地提高会话安全性，尤其是在您还使用客户端变量时

您希望在单个应用程序中的 ColdFusion 页面和 JSP 页面或 servlet 之间共享会话变量。

您希望能够手动终止会话，同时维护客户端标识 cookie 以供客户端范围使用。

您希望支持集群会话；例如，支持服务器之间的会话故障转移。

【问题讨论】：

从内存来看，CF 本地会话不使用会话 cookie，因此可以在浏览器/机器重新启动后持续存在，而所有默认 J2EE 服务器都使用会话 cookie，因此您的会话只能持续与浏览器一样长开了。很久没查这个了，不过可能有用
是的，情况仍然如此，好点。把它放在一个答案中，我会投赞成票，尽管我认为这在渗透测试中是一个负面因素。
Disadvantages of J2EE session management in ColdFusion的可能重复

标签： session jakarta-ee coldfusion

【解决方案1】：

使用 Java EE 会话 cookie 没有严重的缺点，使用它们也有一些优点，正如您在上面的问题中指出的那样。

Java EE 令牌的一个缺点是无法以编程方式轻松修改 cookie。 CF 代币可以。您可以将 CF 令牌修改为仅限会话。您还可以将它们修改为仅 SSL 和 httpOnly。

您也可以使 Java EE 令牌仅 SSL 和 httpOnly，但它涉及 JVM 参数。

在 CF9 中，Adobe 还改进了 CF 令牌的随机性，使其更接近 Java EE 令牌。

我真的认为您使用哪一个并不重要（假设您使用的是 CF9 或更高版本）。但是 Java EE 令牌最接近开箱即用的安全工作。但是，如果您想超越仅将 cookie 设置为“仅会话”并且让它们成为仅 SSL 和 httpOnly，您将需要深入研究 JVM 设置。你不能在你的 App.cfc 中这样做。

【讨论】：

嘿，Arjan，你错过了一个。 #nitpickyuch？
嘿，谢谢。没有@，我之前没有收到您的消息，但我会立即更改它；）
@ArjanTijms 在 ColdFusion 中，它们被称为 J2EE 会话 cookie。在 ColdFusion 相关问题中将它们重命名为 Java EE 会话 cookie 是不合适的，即使它们现在是正式名称。
如果您查看 Arjan 的历史，他似乎喜欢通过 StackOverflow 并将 J2EE 和 JEE 更改为“Java EE”。可能是强迫症。也许是某种爱好。也许为徽章而努力。看起来他已经完成了数百次。
@JasonDean 至于为 SO 做贡献并不是每个人的爱好，重命名也不是专门的爱好。我只是想帮忙。 SO 也将标签 j2ee 重命名为 java-ee。有一个使用术语“J2EE”和另一个“Java EE”的类似问题可能无助于任何人搜索该站点。

【解决方案2】：

CF 本地会话不使用会话 cookie，因此可以在浏览器/计算机重新启动后持续存在，而所有 Java EE 服务器默认使用会话 cookie，因此您的会话只能在浏览器打开时持续。

我找不到在 Servlet JSR 中指定此行为的位置，但在 Servlet Spec 3.0（即不是 JRun）中，您可以为 Java EE 会话 cookie 设置到期日期以模仿 CF 本机会话行为.

正如 nosilleg 所提到的，这可能是一个好处，但也可能被视为一个安全问题，具体取决于您正在开发的应用程序的安全要求。

【讨论】：

【解决方案3】：

ColdFusion 中 J2EE 会话变量的主要缺点之一是，诸如使它们成为 "secure" cookies 之类的更改发生在实例范围内。

这意味着在该实例上运行的每个站点都必须在 https 下运行，包括 ColdFusion 管理员本身。对于托管多个需要会话的站点的服务器，这通常是有问题的。此外，如果您从内置 Web 服务器运行 ColdFusion Administrator，则需要一些过程才能使其在 ssl 下运行。

如果您需要 J2EE cookie 的记录优势，并且需要 cookie 是安全的，那么所有需要会话的站点都必须在 https 上。

如果您不需要 J2EE cookie 的任何记录优势，并且您正在运行 CF9 或更高版本，那么您最好使用 ColdFusion cookie。

请注意，Railo 仍然存在相同的问题，但具有更大的灵活性，因为 cfapplication 标记具有 sessiontype 属性，您可以在其中选择 j2ee 或 cf 每个站点的会话 cookie。

【讨论】：

【解决方案4】：

我有一个小问题，我在请求之间完全丢失了会话变量。我正在使用带有 J2EE 会话的 cfhttp 帖子。想象一下这个场景： 1. wwwRoot/test 文件夹中的 call.cfm 调用也在同一文件夹中的索引页面。 2. index.cfm 将请求发送到 wwwRoot/test/controller/login.cfm。 3. login.cfm 设置一些会话变量并将用户发送到 wwwRoot/test/index.cfm 4. index.cfm 看不到创建的会话变量。

所有的发送请求都是通过带有 addtoken="yes" 的 cflocation 完成的。

关闭 J2EE 会话变量，中提琴！它按应有的方式工作。

cflocation and session variables

【讨论】：