登录系统设计允许每个用户一次登录一台计算机

时间:2010-01-27 13:43:39

标签: php javascript login

我应该如何设计登录系统,以便每个用户名一次只能在一个地方登录?我想让用户不要将用户名提供给其他人登录,这样他们就可以避免为每个用户付费。

如果用户已经登录并尝试登录另一台计算机,我应该阻止第二次登录(如果用户在工作时登录然后尝试在家中继续,这可能是个问题)?或者我应该允许第二次登录并结束第一次登录?或者有人有更好的建议吗?

8 个答案:

答案 0 :(得分:7)

一些Instant Messenger(只能使用一个已登录的端点)可以很好地解决这些冲突。他们显示了像

这样的消息
  

您已从<COMPUTERNAME>

登录

(如果是网络应用,则为<IP/Browser>

并在

之间进行选择
  • 将该登录保持活动状态(并且不从您正在使用的计算机登录)或
  • 结束现有登录(并登录当前计算机)。

这在技术上是最具挑战性的,但绝对是最友好的方式 - 它确保用户只有一个会话在运行,而不是太明显。用户无法登录,因为他们忘记了在工作中退出等等,没有坏血。

答案 1 :(得分:2)

暴雪的“魔兽世界”我相信能够很好地实现它。

基本上,如果您在登录后尝试登录游戏,则会启动第一个连接。

这基本上只需要将会话存储在数据库中。存储会话数据时,也存储用户名。当用户登录时,删除具有该用户名的任何会话记录,然后为登录的人创建一个新记录。

我不建议阻止'新'人尝试登录,因为用户不想因为忘记退出而不得不回到他们拥有的另一台计算机(可能在数英里之外)。


您可能还需要考虑其他一些事情。像sessionid劫持的事情。如果用户只是使用正确的sessionid将cookie放在他们的系统上(这总是可行的话),那么他们可能会在多台计算机上使用相同的会话。在这种情况下,您可能希望保留一个IP字段,用于保存当前登录的数据。

答案 2 :(得分:2)

解决此问题的典型方法是使用

不活动超时时间。

此系统强制执行每个帐户的最大登录次数,同时考虑到上述情况:用户离开办公室时没有退出,并尝试从他/她的家庭工作站登录。

以下是此类系统的一般行

  • 每个帐户都与允许的多个并发登录(又称“席位”)相关联(似乎OP希望每个帐户只有一个,但这可能更多,并且因帐户而异)。 / LI>
  • 许可证管理器逻辑会保留当前登录的所有帐户/用户的列表,以及带有“最后”活动的时间戳。
  • 在提供任何页面之前,Web应用程序会调用许可证管理器(LM)。目的是允许LM更新“最后”活动的时间戳,但也可以在获得许可证时拒绝接听电话(详见下文)
  • 每次登录时,许可证管理器逻辑都会验证所占用的座位数是否超过为该帐户指定的金额。
  • 如果不是这种情况,LM只会将当前会话添加到活动会话列表
  • 如果是这种情况,LM会检查列表中超过超时期限的会话。如果找到一个,则禁用它,并授予对新登录的访问权限。如果未找到,则拒绝登录。
  • 在每次[显式]注销时,LM从活动会话列表中删除相应的会话。

请注意,上面概述的一般原则可能会有一些变化,特别是:

  • 而不是默默地和系统地使[通常最老的]超时会话无效,可以通知当前尝试记录这种情况的用户并让他/她决定是否需要“杀死”这样的会话。
  • 为了避免LM对每个新的页面请求造成负担,Web应用程序可以在每个会话的基础上跟踪自LM中最后一次“刷新”会话以来的时间,并且仅在调用LM时调用LM时间超过了超时期限的1/3。

独立于LM逻辑本身,请记住保留所有LM相关事件的日志(登录,注销,非活动会话“杀死”,拒绝登录......)。此类日志应包括日期/时间,IP地址和其他相关信息,在解决与被盗密码等相关的问题时非常有用。此类日志还包含非常有价值的营销,例如,查找所有似乎拥有太少座位的帐户(因此可能购买一些ugrade),或查找风险帐户等。

还有一些注意事项

  • 让用户轻松注销(在每个页面的固定位置注销按钮/链接
  • 让用户轻松报告冲突/被盗密码情况

答案 3 :(得分:1)

阻止首次登录。如果您在家中登录,那么在工作中,您不希望被阻止,因为这是一种合法的方法。始终允许登录当前,并删除旧的。

答案 4 :(得分:1)

我建议跟踪每个用户是否已登录并允许第二次登录结束第一次登录的会话。

然后允许会话结束的用户在错误启动时报告可能的欺诈活动。

答案 5 :(得分:0)

不要试图通过计算用户拥有活动会话的IP地址数量来做到这一点 - 某些用户可能落后于负载平衡代理。

解决方案是编写自己的会话处理程序 - 可能最简单的数据库后端 - 并且只允许一个用户拥有一个打开的会话。

您可能希望调整会话垃圾回收和不活动。您还应该确保您的系统免受会话固定攻击。

下进行。

答案 6 :(得分:0)

就安全性而言,这就是您所获得的,无论如何将会话数据存储在数据库中总是一个好主意。特别是如果你在共享服务器上。

对于允许哪个用户以及哪个用户来说这是一个由您来判断的问题。我想你可以有一些二级形式的身份证明,以确保他们是帐户的真正所有者。实际签约的人。

答案 7 :(得分:0)

我之前在具有相同要求的Web应用程序中完成了此操作。这是我做的:

当有人登录时,您会生成GUID并将其存储在数据库中,并附加到用户。您还将相同的GUID存储在会话cookie中。

每次登录用户访问您网站上的任何页面时,都会检查其Cookie GUID并将其与数据库中分配给它们的GUID进行比较。如果这些GUID不匹配,则他们已在另一台计算机上登录,并将其从该会话中注销。

这种方法效果很好。