客户端会话
我希望几个相关网络应用程序的客户端保持自己的身份验证状态。这提高了可伸缩性，因为集群节点之间不需要复制会话。它使得 Java Servlet 和 PHP 等不同服务器技术的集成变得更加容易。
我的计划如下：
- 在客户端身份验证后，使用用户名和会话过期时间设置一个签名和加密的cookie。
- 当客户端发送请求时，服务器会解密并验证 cookie，并根据 cookie 值授予或拒绝访问权限。
- 会话过期时间将通过重置 cookie 来更新。
所有想要使用会话的服务器只需要知道cookie机制和解密密钥。另请参阅：客户端层中的会话状态
这种方法可以吗？是否可以将其集成到 servlet 容器/应用程序服务器中，以便它对应用程序透明？例如，Servlet 应该能够使用 HttpServletRequest#getRemoteUser()。这可能吗？或者我需要容器级别之上的东西，比如 Spring Security？是否有用于客户端会话管理的现有库？
I want the clients of several related web apps to hold their own authentication state. This improves scalability, because no session replication between cluster nodes is needed. And it makes integration of different server technologies like Java Servlets and PHP easier.
My plan is as follows:
- Set a signed and encrypted cookie with the user name and session expiration time after client authentication.
- When the client sends a request, the server decrypts and validates the cookie and grants or denies access depending on the cookie values.
- The session expiration will be updated through resetting the cookie.
All servers that want to use the session have only to know the cookie mechanism and the decryption key. See also: Session state in the client tier
Is this approach ok? Would it be possible to integrate it into a servlet container / application Server so that it is transparent to the applications? A servlet should be able to use HttpServletRequest#getRemoteUser() for example. Is this possible? Or would I need something above the container level like Spring Security? Are there any existing libraries for client side session management?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这不是一个好主意。在我看来，无论加密与否，将会话过期和用户名等重要数据完全存储在客户端都太危险了。即使这个概念本身在技术上是安全的（我无法深入回答这个问题，我不是加密专家），只需获取您的加密密钥，就可以在不损害您的服务器的情况下实现闯入。
掌握密钥的人可以随意生成会话 cookie，在任意时间长度内冒充任何用户，这是经典会话概念旨在防止的情况。
对于这个问题有更好的、可扩展的解决方案。例如，为什么不建立一个所有关联服务器和服务都可以轮询的中央会话验证实例？环顾网络，我 100% 确信有现成的解决方案可以满足您的需求。
Not a good idea. Storing vital data like session expiry and user name entirely on client side is too dangerous IMO, encrypted or not. Even if the concept is technically safe in itself (I can't answer that in depth, I'm no encryption expert), a break-in could be facilitated without compromising your server, just by acquiring your encryption key.
Somebody who gets hold of the key could generate session cookies at will, impersonating any user for any length of time, something the classical session concept is designed to prevent.
There are better and scalable solutions for this problem. Why not, for instance, set up a central session verification instance that all associated servers and services can poll? Look around on the web, I am 100% sure there are ready-made solutions addressing your needs.
我不同意发帖者所说的这种方法不安全的观点。它的变体被用于许多备受推崇的框架中，例如 Rails 和 Play！，正是出于您概述的原因，并且在正确实现时它是完全安全的。
I disagree with the posters saying this approach is not secure. Variants of it are used in a number of well respected frameworks, such as Rails and Play!, for precisely the reasons you outline, and it's perfectly secure when implemented correctly.
首先，使用 HTTP 会话并不会真正阻止您进行扩展，即使在使用 HTTP 会话状态复制时也是如此（顺便说一下，某些机制比其他机制更智能，例如 WebLogic 的 内存复制没有很大的开销）。第二，你真的需要它吗？大多数应用程序（大多数）不需要会话复制。第三，我的理解是否正确：您打算根本不使用 HTTP Session 吗？
不要这样做！不要在 cookie 中存储服务器使用的用户名和其他敏感数据，这是一个非常糟糕的主意！您实际上需要承认，有人弄清楚您的系统如何工作并破坏它只是时间问题（特别是如果您的 cookie 是 crib 攻击）。所以，实际上，您应该将数据存储在服务器端的 Session 中，并且只将 ID 存储在 cookie 中，就像实际工作一样。这样就安全多了。
不。并且您不需要这个来实现互操作单点登录（如果这是您想要构建的）。只需使用集中式身份验证解决方案，例如
CASJasig，它具有各种技术的库。First, using HTTP Session doesn't really prevent you from scaling, even when using HTTP Session State replication (some mechanisms are smarter than others by the way, for example WebLogic's in-memory replication doesn't have a big overhead). Second, do you really need it? Most applications (the majority) don't need Session replication. Third, am I understanding right: do you plan to not use HTTP Session at all?
Don't do this! Don't store a username and other sensible data used by the server in a cookie, this is a very bad idea! You actually need to admit that it's just a matter of time before someone figures out how your system works and breaks it (especially if your cookie is candidate for crib attacks). Sor, really, you should store data in the Session on the server-side and only an ID in the cookie, like things are actually working. This is much more secure.
No. And you don't need this for interoperable single-sign on (if this is what you are trying to build). Just use a centralized authentication solution like
CASJasig which has libraries for various technologies.这实际上并不是会话的实现方式。 cookie本身不需要携带会话本身的任何数据，它只是对它的引用。
Cookie 保存的通常是一个
会话 ID，然后将其链接到服务器上的数据。如果您没有可供其他服务器访问的中央数据会话服务器，我建议您购买一个:)。
This is not really how Sessions are implemented. The cookie itself doesn't need to carry any data of the session itself, it's just a reference to it.
What the Cookie holds is usually a
Session IDwhich is then linked to the data on the server.If you don't have a central data session server for the other servers to access, I suggest to get one :).
您可以通过使用状态服务器来避免集群环境中的数据重复，该服务器为集群中的所有节点所熟知，并维护所有用户的会话数据。每次用户执行请求时，都会向应用程序服务器发送一个带有会话 ID 的 cookie；这个应该从状态服务器检索会话。这对于 ASP.NET 开发来说是可能的，但我不确定 Java 支持这种方法有多容易。
You can avoid duplication of data in a clustered environment by using a state server - a server that is well known by all the nodes in the clusters and maintains the session data for all the users. Every time a user performs a request, it send a cookie with session id to the applications server; this one should retrieve the session from the state server. This is possible for asp.net development, but I'm not sure how easy Java supports this approach.
正如佩卡所说，这不是一个好主意。人们可以用敏感的会话数据拦截您的 cookie。即使使用 SSL，通过使用 fiddler2 也可以解密流量
As Pekka said, not a good idea. One can intercept your cookie with sensitive session data. Even with SSL, by using fiddler2 one can decrypt the traffic