胖客户端和服务器之间的会话管理？
我的应用程序是 Eclipse 胖客户端，我想添加身份验证和授权功能。我的用户和角色存储在数据库中，我的应用程序还有一个基于 Web 的管理控制台，可让我管理用户和角色。我在此管理控制台上利用 Spring 安全性。
所以这是我的要求：
我希望我的胖客户端为用户提供登录对话框。身份验证需要在服务器端（可能是 Web 服务）执行，并且角色必须流入胖客户端。我还想以某种方式管理服务器端的会话。
我真的想不出任何简单的方法来做到这一点。我知道如果我使用 Spring Rich Client，它会与服务器端的 Spring Security 很好地集成。 但是，目前这对我来说不是一个选择。
请分享您对如何实现这一目标的想法。感谢您的帮助。
My application is a Eclipse Rich Client and I would like to add authentication and authorization features to. My Users and roles are stored in a database and my application also has a web based admin console which lets me manage users and roles. I am leveraging Spring security on this admin console.
So here's my requirement:
I would like my thick client to provide users with a login dialog box. The authentication would need to be performed on the server side (it could be a webservice) and the roles have to flow in to the thick client. I would also like to manage sessions on the server side, somehow.
I really can't think of any easy way to doing this. I know that if I were to use Spring Rich Client, it would integrate pretty well with Spring Security on the server side.
But, that is not an option for me at this point.
Please share your thoughts on how to acheive this. Appreciate your help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
由于您倾向于 Web 服务（听起来像您），我会考虑从您的富客户端获取用户信息（我假设用户 ID 和密码），使用 WS-Security 将加密信息发送到 Web 服务，并让 Web 服务执行身份验证工作。另外，我会考虑 Web 服务返回您想要返回到富客户端的有关用户的任何信息（名字/姓氏等）。
Since you're leaning toward web services (it sounds like you are) I'd think about taking the user information from your rich client (I assume user ID and password), using WS-Security to send the encrypted info to a web service, and having the web service do the auth stuff. Also I'd think about the web service returning any info that you want to go back to the rich client about the user (first/last name, etc).
我最近使用挑战-响应-身份验证开发了一个类似的应用程序。基本上，您的 Web 服务或服务器上有三个方法
getChallenge 返回一个值（例如一些随机值或时间戳），客户端使用他/她的密码进行哈希处理并将其发送回 getSession。例如，服务器将用户名和挑战存储在地图中。
在 getSession 中，服务器计算相同的哈希值并与客户端的响应进行比较。如果正确，则会生成、存储会话密钥，并将其发送到使用用户密码加密的客户端。现在，每次调用 getData 都可以使用会话密钥加密数据，并且由于客户端已经在 getSession 中进行了验证，因此他/她不必再次“登录”。
这样做的好处是密码永远不会以纯文本形式发送，并且如果有人正在侦听，由于密码是用随机值进行哈希处理的，因此对 getSession 的调用将很难伪造（例如通过重放调用）。由于 getSession 中的密钥是使用用户密码加密发送的，因此犯罪者必须知道密码才能破译它。最后，您只需验证用户一次，因为对 getData 的调用将使用用户会话密钥对数据进行加密，然后就不必再“关心”了。
I developed a similar application recently using the Challenge-Response-authentication. Basically you have three methods in your webservice or on your server
getChallenge returns a value (some random value or a timestamp for instance) that the client hashes with his/hers password and sends back to getSession. The server stores the username and the challenge in a map for instance.
In getSession the server calculates the same hash and compares against the response from the client. If correct, a session key is generated, stored, and sent to the client encrypted with the users password. Now every call to getData could encrypt the data with the session key, and since the client is already validated in getSession, s/he doesn't have to "login" again.
The good thing about this is that the password is never sent in plain text, and if someone is listening, since the password is hashed with a random value, the call to getSession will be hard to fake (by replaying a call for instance). Since the key from getSession is sent encrypted with the users password, a perpetrator would have to know the password to decipher it. And last, you only have to validate a user once, since the call to getData would encipher the data with the users session key and then wouldn't have to "care" anymore.
我想我也有类似的要求。在我们的例子中：
在我们的例子中，我们有很多特权需要考虑，而不仅仅是布尔值“有或没有访问权限”。我正在考虑做的是生成一个全局唯一的会话令牌/密钥（例如 java.util.UUID），胖客户端将其保留在某种本地 ThickClientSession 对象中。
每次胖客户端发起操作时，例如调用 getLatestDataFromServer()，该会话密钥就会传递到服务器。
应用程序服务器（例如，在 Tomcat 下运行的 Java Web 应用程序）本质上是无状态的，除了此会话密钥的记录之外。如果我在上午 10 点登录，那么应用程序服务器会将会话密钥记录为在上午 10:20 之前有效。如果我在上午 10:05 请求数据，会话密钥有效期将延长至上午 10:25。会话伴随的各种权限级别也保存在状态中。这可以通过以 UUID 为键的简单 Map 集合来完成。
至于如何进行这些调用：我推荐Spring HTTP Invoker。这很棒。您不需要完整的 Spring Rich Client 基础设施，它可以很容易地集成到任何 Java 客户端技术中；例如，我使用 Swing 来执行此操作。出于安全目的，可以将其与 SSL 结合使用。
无论如何，这大致就是我计划解决这个问题的方式。希望这有点用！
I've a similar requirement I think. In our case:
In our case we have many privileges to consider, not just a boolean "has or has not got access". What I am thinking of doing is generating a globally unique session token/key (e.g. a java.util.UUID) that the thick client retains in a local ThickClientSession object of some sort.
Every time the thick client initiates an operation, e.g. calls getLatestDataFromServer(), this session key gets passed to the server.
The app server (e.g. a Java webapp running under Tomcat) is essentially stateless, except for the record of this session key. If I log in at 10am, then the app server records the session key as being valid until 10:20am. If I request data at 10:05am, the session key validity extends to 10:25am. The various privilege levels accompanying the session are held in state as well. This could be done via a simple Map collection keyed on the UUID.
As to how to make these calls: I recommend Spring HTTP Invoker. It's great. You don't need a full blown Spring Rich Client infrastructure, it can be very readily integrated into any Java client technology; I'm using Swing to do so for example. This can be combined with SSL for security purposes.
Anyway that's roughly how I plan to tackle it. Hope this is of some use!
也许这会对您有所帮助：
http://prajapatinilesh.wordpress.com/2009/01/14/manually-set-php-session-timeout-php-session/
特别注意这一点（用于强制垃圾收集）：
还有另一个变量称为session.cookie_lifetime 您可能也需要更改。
IIRC，您必须设置至少 2 个（可能更多）变量。我一辈子都不记得它们是什么，但我确实记得有不止 1 个。
Perhaps this will help you out:
http://prajapatinilesh.wordpress.com/2009/01/14/manually-set-php-session-timeout-php-session/
Notice especially this (for forcing garbage collection):
There is also another variable called session.cookie_lifetime which you may have to alter as well.
IIRC, there are at least 2, possibly more, variables that you have to set. I can't remember for the life of me what they were, but I do remember there was more than 1.