在基于验证性MVC和授权模型的Web应用程序中，我们最近已迁移到Spring MVC。
作为此举的一部分，我们还将考虑将本地创建的GUID(随每个请求一起传递)转移到基于cookie的Session ID。
从表面上看，在我们看来，这样做将是一个很大的缺点，因为标准JSESSION / HttpSession似乎是所有安全弊端的根源:
会话固定(在现有代码中，仅在成功登录后创建会话，因此我们永远不需要使会话无效()。 CSRF-会话永远不会作为cookie传递，因此永远不会有风险(上帝，这是一个有问题的处理方法，因为没有真正的框架或通用解决方案可以检查HDIV和CSRFGuard)。 测试可用性-QA可以轻松地使具有多个角色的多个用户连接到同一服务器，而JSESSION则不可能。 在各种容器(Weblogic，JBOSS和Websphere)中一致的HTTPSession创建和失效中在HTTP到HTTPS之间移动时，JSession处理不一致。
因此，除了“成为标准”的明显优势之外，关于我为什么要走JSESSION路线的任何线索？ 关于您为什么应该或不应该使用jsession的回答并不是真正的绝对答案，但是对您的担忧不屑一顾:
您的应用程序不应依赖于会话是否存在的事实。它应该基于这样的事实，即会话根据您施加的某些规则(用户身份验证，分配给该用户的角色等)有效。 CSRF并不是什么大问题，只要您注意不要将GET用于明智的操作即可，而且正如您提到的Spring MVC一样，使用它很容易实现。 是的，如果您仅依靠一个浏览器。另外，尽管在某些情况下仍然必须进行手动测试，但是许多用例可以从自动化中受益，从而减少了从一个角色切换到另一个角色的影响。 永远不会遇到问题。但是我试图使会议的内容尽可能的小。 那是一件好事。它可以防止您在不注意的情况下离开安全连接。
现在，无论您选择什么选项，总会有一些弊端。在每个请求中(因此可能在每个GET URL中)都具有UUID不能使您的用户轻松使用书签。也无法保持会话状态。