迭代现有的 Session 对象
我希望能够在有人登录时终止同一用户名的现有会话,以防止多人使用同一登录名。
有没有办法迭代现有会话并终止它们?
I want to be able to kill existing sessions for the same username when someone logs in to prevent multiple people from using the same login.
Is there a way to iterate through existing sessions and kill them?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
将其添加到您的 global.asax
现在您可以像这样迭代您的会话
为了终止其他会话,您可以检查旧会话的
Session_Start
方法放弃它。看起来可能是这样的。Add this to your global.asax
Now you can iterate through your sessions like this
In order to kill other sessions in you could check in the
Session_Start
method for the old session abandon it. That might look something like this.您可以将登录的用户保存到数据库并检查他们是否已经登录,您可以防止他们再次登录。使用 Global.asax 下的 Session_Start 方法。
you can save the logged users to database and check if they have already logged in, you can prevent them to login again. using the Session_Start method under Global.asax.
简短的回答:不。
长答案:您需要实现自己的会话提供程序。出于安全原因,一个会话无法引用任何其他会话。您必须四处走动并实施自己的会话管理。
Short answer: no.
Long answer: you need to implement your own session provider. There's no way for one session to reference any other session, for security reasons. You'd have to go around and implement your own session management.
当我实现这一点时,我将用户 ID(或唯一的东西)存储在应用程序变量、字典或数组中。登录时可以轻松检查应用程序词典中是否存在用户 ID。唯一真正的问题是人们不注销并只是关闭浏览器。您永远找不到一种可靠的方法来检测此事件。
The one time I implemented this, I stored user ids (or something unique) in an Application variable, a Dictionary or an Array. It's easy to check for the existence of the User ID in the Application Dictionary at log in time. The only real issue is people who don't log out and just close the browser. You'll never find a good reliable way to detect this event.
即兴:
在 Session_Start(通常是成功登录)时,将用户的 UserID 和 SessionID 存储在查找表(或用户表中的新列)中。
对于每个请求,您需要验证 UserID(存储在 Session 中)和 SessionID 是否与 Lookup 表中存储的值匹配,作为身份验证步骤。
Off the cuff:
On Session_Start (usually a successful login), in store the user's UserID and SessionID in a lookup table (or new column in the user table).
On each request you would need to validate that the UserID (stored in Session) and SessionID match the values stored in the Lookup table as an authentication step.