存储登录的用户详细信息

我建议存储ID而不是对象。缺点是,每次想要获取该用户的信息时都必须访问数据库。但是,除非页面中每毫秒都有计数,否则性能不应该是问题。以下是两个优点:

1. 如果用户的信息以某种方式发生了变化,那么您就不会在会话中存储过期的信息。例如,如果一个用户被管理员授予了额外的特权,那么这些特权将立即可用,而不需要用户注销然后重新登录。

2. 如果会话信息存储在硬盘上,则只能存储可序列化数据。因此,如果您的用户对象曾经包含数据库连接、打开套接字、文件描述符等内容,那么这些内容将无法正确存储,也可能无法正确清除。

在大多数情况下,这些问题不会成为问题,任何一种方法都可以。

为了安全起见,我将生成一个会话ID(guid或加密安全的rng),并拥有一个表,该表只将会话ID映射到用户ID。然后,您只需将会话ID存储在他们的cookie中,并让它作为用户ID的代理。

|Session |UserID |
|--------+-------|
|a1d4e...+ 12345 |
|----------+-------|
|c64b2...+ 23456 |
|----------+-------|

有了这个,没有人可以通过猜测他们的ID来模仿另一个用户。它还允许您限制用户的会话,因此他们必须每隔一段时间登录一次(通常是两周)。如果您想存储关于他们会话的其他数据,您可以将其添加到这个表中。

请记住,如果您在会话中存储了用户的所有属性(这扩展到了权限),那么对用户所做的任何更改在再次登录之前都不会生效。

就我个人而言,我会将姓名和身份证存储起来,以便快速参考,必要时还可以提取其余的身份证。

在大多数情况下,存储ID是最佳实践。其中一个重要原因是可伸缩性。如果您存储用户对象(或数据库中的任何实体,而不仅仅是其ID),那么在扩展为您的站点提供服务的服务器数量时会遇到问题。更多信息,谷歌的“无共享架构”。

我认为这取决于你使用的平台。如果您使用的是ASP.NET,那么我肯定会看看 FormsAuthentication 类和所有内置(和可扩展)功能,可用于存储登录的用户设置。

我将存储用户ID和会话ID的哈希值,然后将其匹配到数据库的会话表中。这样就很难欺骗会话数据。我可以再检查一下IP吗?

不确定我是否希望依赖存储在会话变量中的用户ID,并相信它是该用户,因为它可以很容易地进行更改,并作为另一个成员获得访问权。

我通常将用户存储在会话中。在进行更改后,可以用新副本替换会话中的对象,从而解决登录前无法更改的问题。

我们的用户对象相当轻,所以我们选择将其存储在会话变量中。不确定这是否是最有效的,但到目前为止它工作得很好。