ASP.NET用户配置文件与使用Cookie

对于匿名用户来说,将pref存储在cookie中似乎相当明智——你不知道它们是谁,也不知道它们是否会回来,正如你所说,您无法从一个会话到下一个会话确定他们是谁,但是您最好在cookie中存储某种令牌,并将其映射到服务器上的首选项存储。

另外,我注意到不同的浏览器有不同的cookie实现——例如IE现在可以 receive 50 cookies 从一个域(从原来的20个域增加),但仍限于 4096 bytes for the entire cookie collection (和以前的版本)-其他浏览器将支持每个cookie 4KB,而不是每个域4KB。

将所有首选项数据保存在cookie中的另一个缺点是,每当对数据进行更改时,客户端的每个请求和服务器的任何响应都必须发送所有这些数据。虽然这似乎是宽带时代的一个小问题,但仍然是额外的开销。使用Profiles API意味着数据保存在服务器上,浏览器只需要发送会话标识cookie。

此外,如您所述,对于匿名用户,如果删除了cookie,则Profiles DB中保存的用户首选项将不再可访问。但是,您网站的注册用户将不会出现这种情况。如果他们删除了cookie,服务器在下次登录时仍然能够检索他们的用户首选项。

Cookie的最大长度是有限的,并且它们使用的实现超出了您的控制范围(毕竟,它们是访问者浏览器的一项功能)。就我个人而言,我不喜欢依赖未知的第三方实现,我没有任何控制权,如果必须的话,我会尽量以最简单的方式使用它。

因此,在我的家乡,我总是将用户数据存储在服务器上,然后传递一个指向该信息的cookie。

• 您正在对用户隐藏您的实现:如果您将数据存储在cookie中,任何人都可以看到它,并且可以随意分析或修改它。这甚至会导致用户将cookie更改为他们喜欢的cookie,从而迫使您保留您可能想要丢弃的东西,因为有些用户随时都依赖于您的特定实现。
• 由于Cookie以明文形式存储在共享机器上,因此每个人都无法再轻松查看以前用户所做的所有设置,也无法随意更改它们。

但最重要的一点仍然是与不太正常工作的浏览器实现的断开(仅存储小令牌是常见的、经过测试的用例)

不要忘记,使用cookie的最大缺点之一是它们可以被复制,因此在cookie上存储身份验证信息是危险的。

我不熟悉用户配置文件API,但我猜它将信息存储在服务器上(?)。如果是这样的话,那么如果你有很多用户,你可能会有问题。

总的来说,如果用户配置文件保证了信息的持久性,那么最好的解决方案可能是使用用户配置文件。

请记住,可以编写一个ProfileProvider,将用户数据持久化到cookie中,这样,如果您确定要持久化的状态适合于cookie(大小、安全性等),您就可以两全其美。

实际上,在使用ASP.NET配置文件提供程序时,您不需要在匿名用户的cookie中保留首选项数据。只需在cookie中存储当前用户ID(这是一个看起来很可怕的会话相关字符串)。这将成为后续访问中的前一个用户ID,然后您只需获取旧的配置文件信息并将其迁移到当前配置文件,甚至可以将其作为旧的匿名配置文件进行身份验证。