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

时间:2009-01-19 11:20:02

标签: asp.net cookies profile

我认为,在几乎所有情况下,用户偏好数据都可以存储在cookie中,其结果与使用User Profile API时(几乎)一样好。使用cookie(对于经过身份验证的用户)的缺点似乎是可以删除cookie或超时,在这种情况下,用户首选项数据将丢失。对于匿名用户,如果需要跨会话保留首选项数据,则即使使用用户配置文件也必须使用cookie。

那么使用用户配置文件或cookie存储用户偏好的一些最大的优点/缺点是什么?

6 个答案:

答案 0 :(得分:3)

在网站上注册的一个好处是它会记住我的偏好 - 如果你将这些信息存储在我的机器而不是服务器上的cookie中,那么当我从另一台计算机登录你的网站时,我我必须重新设置我的所有偏好 - 从可用性的角度来看,这是相当糟糕的。

对于匿名用户,将prefs存储在cookie中可能看起来相当明智 - 您不知道他们是谁,或者他们是否会回来,并且如您所述,您无法在一个会话中工作到接下来他们是谁 - 但是你可能最好在cookie中存储某种令牌并将其映射到服务器上的首选项存储。

另外,我注意到不同的浏览器对cookie有不同的实现 - 例如IE现在可以receive 50 cookies来自一个域(从原来的20个),但它仍然限于总共{{3 (和之前的) - 其他浏览器将支持每个cookie 4KB,而不是每个域。

答案 1 :(得分:2)

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

因此,从我来自的地方,我总是将用户数据存储在服务器上,只是传递一个指向该信息的cookie。

除了不信任浏览器之外可能有大量数据(可能丢失,存储不正确或根本不存储,这取决于浏览器,还有一些防病毒应用程序或其他),这有各种各样的其他优点:

  • 您正在隐藏用户的实现:如果您将数据存储在Cookie中,则对任何人都可以看到,并且可以随意分析或修改。这甚至可以导致用户将cookie更改为喜欢的内容,从而迫使您保留周围的东西,可能只是因为某些用户在任何时候都依赖于您的特定实现而无法摆脱。
  • 由于Cookie以纯文本形式存储在共享计算机上,因此每个人都无法再轻松查看以前用户所做的所有设置,也无法随意更改。

但最重要的一点仍然是与不太完善的浏览器实现的脱节(只是存储小代币是常见的,经过测试的用例)

答案 2 :(得分:2)

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

此外,如您所述,对于匿名用户,如果删除了Cookie,则无法再访问“个人档案”数据库中保存的用户首选项。但是,对于您网站的注册用户,情况并非如此。如果他们删除了他们的cookie,服务器仍然可以在他们下次登录时检索他们的用户偏好。

答案 3 :(得分:1)

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

我不熟悉User Profile API,但我猜它会将信息存储在服务器上(?)。如果是这样的话,那么如果你有很多用户就会遇到问题。

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

答案 4 :(得分:1)

请记住,可以编写一个将用户数据保存在cookie中的ProfileProvider,因此如果您确定要保留的状态适合于cookie(大小,安全性等),那么您可以充分利用这两个世界。

答案 5 :(得分:1)

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