我认为，在几乎所有情况下，用户偏好数据都可以存储在 cookie 中，其结果（几乎）与使用 User Profile API 时一样好。使用 cookie（对于经过身份验证的用户）的缺点似乎是 cookie 可以被删除或超时，在这种情况下，用户首选项数据将丢失。对于匿名用户，如果偏好数据需要跨会话持久保存，那么即使使用用户配置文件也必须使用 cookie。
那么使用用户配置文件或 cookie 存储用户偏好的最大优点/缺点是什么？
问问题
4165 次
6 回答
3
在网站上注册的好处之一是它可以记住我的偏好——如果您将该信息存储在我机器上的 cookie 中，而不是在您的服务器上，那么当我从另一台计算机登录您的网站时，我必须再次设置我所有的偏好 - 从可用性的角度来看，这相当糟糕。
对于匿名用户，将首选项存储在 cookie 中似乎相当明智——您不知道他们是谁，也不知道他们是否会回来，而且正如您所说，您无法从一个会话到下一个会话是 - 但是您最好将某种令牌存储在 cookie 中并将其映射到服务器上的首选项存储。
另外，我注意到不同的浏览器对 cookie 有不同的实现——例如，IE 现在可以从一个域接收 50 个 cookie（从原来的 20 个增加），但它仍然限制为整个 cookie 集合的总数为 4096 个字节（和以前的） - 其他浏览器将支持每个 cookie 4KB，而不是每个域。
于 2009-01-19T12:07:35.330 回答
2
Cookie 的最大长度是有限的，并且它们使用的是您无法控制的实现方式（毕竟，它们是您的访问者浏览器的一项功能）。就个人而言，我不喜欢依赖我无法控制的未知第三方实现，如果必须，我会尝试以最简单的方式使用它。
因此，从我来的地方，我总是将用户数据存储在服务器上，然后传递一个指向该信息的 cookie。
除了不信任浏览器可能有大量数据（这些数据可能会丢失、错误存储或根本不存储，这不仅取决于浏览器，还取决于某些防病毒应用程序等），这还有其他各种优点：
- 您正在向用户隐藏您的实现：如果您将数据存储在 cookie 中，那么任何人都可以看到它，并且可以随意分析或修改。这甚至可能导致用户将 cookie 更改为喜欢的内容，从而迫使您保留您可能想要摆脱的东西，因为某些用户随时依赖于您的特定实现。
- 由于 cookie 以纯文本形式存储在共享机器上，每个人都无法再轻易看到之前用户所做的所有设置，也无法随意更改它们。
但最重要的一点仍然是与不太正常的浏览器实现断开连接（仅存储小令牌是常见的、经过测试的用例）
于 2009-01-19T11:31:48.473 回答
2
将所有偏好数据保存在 cookie 中的另一个缺点是，无论何时对数据进行更改，都必须在来自客户端的每个请求以及来自服务器的任何响应中发送所有这些数据。虽然这在宽带时代似乎是一个小问题，但它仍然是一个额外的开销。使用 Profiles API 意味着数据保存在服务器上，浏览器只需要发送一个会话标识 cookie。
此外，正如您所说，对于匿名用户，如果 cookie 被删除，则将无法再访问 Profiles DB 中保存的用户首选项。但是，对于您网站的注册用户而言，情况并非如此。如果他们删除了他们的 cookie，服务器仍然能够在他们下次登录时检索他们的用户偏好。
于 2009-01-19T11:37:21.553 回答
1
不要忘记使用 cookie 的最大缺点之一是它们可以被复制，因此在它们上存储身份验证信息是很危险的。
我不熟悉用户配置文件 API，但我猜它会将信息存储在服务器上（？）。如果是这种情况，那么如果您有很多用户，您可能会遇到问题。
总的来说，如果能保证信息的持久性，最好的解决方案可能是使用用户配置文件。
于 2009-01-19T11:32:21.423 回答
1
请记住，可以编写将用户数据保存在 cookie 中的 ProfileProvider，因此如果您确定要保存的状态适合 cookie（大小、安全性等），则可以两全其美。
于 2009-01-19T12:16:38.493 回答
1
实际上，在使用 ASP.NET 配置文件提供程序时，您不需要将偏好数据保存在匿名用户的 cookie 中。只需将当前的用户 ID（这是一些看起来很糟糕的与会话相关的字符串）存储在 cookie 中。这在后续访问中成为以前的 UserID，然后您可以获取旧的个人资料信息并将其迁移到当前个人资料，甚至可以将它们验证为旧的匿名个人资料。
于 2009-04-16T16:19:08.463 回答