维持状态的方式比较答案

【问题标题】：comparison of ways to maintain state维持状态的方式比较
【发布时间】：2008-09-18 18:54:00
【问题描述】：

在 Web 开发中使用多种方法来维护用户状态。

这些是我现在能想到的：

查询字符串
Cookie
表单方法（Get 和 Post）
Viewstate（我猜只有 ASP.NET）
会话（InProc Web 服务器）
会话（专用网络服务器）
会话（数据库）
本地持久性（Google Gears）（感谢 Steve Moyer）等等。

我知道每种方法都有自己的优点和缺点，比如 cookie 不安全，QueryString 有长度限制，而且看起来很丑！ ;)

但是，在设计 Web 应用程序时，我总是对为什么应用程序使用什么方法或要避免什么方法感到困惑。

我想知道的是您通常使用哪些方法，并且会推荐或更有趣的是您希望在某些情况下避免使用哪些方法以及为什么？

【问题讨论】：

标签： state

【解决方案1】：

虽然这是一个非常复杂的问题，但在考虑实现状态时，我有一些简单的想法。

查询字符串状态仅对最基本的任务有用 - 例如，维护用户在向导中的位置，或者提供在用户完成给定任务后重定向到的路径（例如，登录）。否则，查询字符串状态非常不安全，难以实现，并且为了公正起见，它需要通过包含将客户端绑定到服务器为该客户端维护的状态的密钥来绑定到某些服务器端状态机。
Cookie 状态或多或少是相同的——它只是比查询字符串状态更漂亮。但它仍然完全在客户端维护，除非 cookie 中的数据是将客户端与某些服务器端状态机联系起来的关键。
Form 方法状态再次相似 - 它对于隐藏将给定表单与后端的某些数据相关联的字段非常有用（例如，“此用户正在编辑记录 #512，因此表单将包含隐藏的输入值为 512")。它在其他方面没有什么用处，再说一遍，它只是查询字符串和 cookie 状态背后相同想法的另一种实现。
会话状态（您描述的任何方式）都很棒，因为它们可以无限扩展，并且可以处理您选择的编程语言可以处理的任何事情。第一个警告是客户端需要有一个密钥来将该客户端与其存储在服务器上的状态联系起来；这是大多数 Web 框架向客户端提供基于 cookie 或基于查询字符串的密钥的地方。（几乎每个现代人都使用 cookie，但如果未启用 cookie，则使用查询字符串。）第二个警告是，您需要在存储状态的方式上添加一些内容……您会将其放入数据库？您的 Web 框架是否完全为您处理？同样，大多数现代 Web 框架都可以解决这个问题，对于我来说要实现自己的状态机，我需要一个非常充分的理由......否则，我可能会创建安全性随着时间的推移，任何成熟框架中的漏洞和功能损坏都已解决。

所以我想我真的无法想象除了最微不足道的原因之外不想使用基于会话的状态。

【讨论】：

另一方面，查询字符串状态是创建永久链接和搜索引擎优化的唯一选项。
哦，完全 - 我的列表中没有包含它，但这是一个好点。

【解决方案2】：

安全也是一个问题；用户可以轻松更改查询字符串或表单字段中的值。用户身份验证应保存在加密或防篡改 cookie 或服务器端会话中。在用户完成一个过程（例如网站注册）时跟踪表单中传递的值，嗯，这可能会保存在隐藏的表单字段中。

不过，关于查询字符串的好处（有时也很危险）是，任何点击链接的人都可以获取该状态。如上所述，如果它给用户一些他们不应该拥有的授权，这是很危险的。不过，向您的朋友展示您在网站上找到的东西也不错。

【讨论】：

我相信今天使用查询字符串只有两个原因 - 如果我希望人们在单击链接时登陆我网页上的特定位置，并且如果我想验证新用户帐户，他/她点击我发送的电子邮件上的链接。

【解决方案3】：

随着越来越多地使用 Web 2.0，我认为您的列表中缺少两个重要的方法：

8 AJAX 应用程序 - 由于页面不会重新加载并且没有页面到页面导航，因此状态不是问题（但持久化用户数据必须使用异步 XML 调用）。

9 本地持久性 - 基于浏览器的应用程序可以使用 Google Gears 等库将其用户数据和状态持久化到本地硬盘。

至于哪个最好，我觉得各有各的地方，但是Query String方式对于搜索引擎来说是有问题的。

【讨论】：

糟糕... Google Gears 的想法确实让我忘记了。随着 Chrome 的基础越来越大，我想我不能让它滑太久！
哦，很好——Google Gears 是另一种思考它的好方法。我认为它再次非常类似于基于会话的状态，并且会类似地考虑它，但它肯定从列表中丢失。

【解决方案4】：

就个人而言，由于我几乎所有的 Web 开发都是在 PHP 中进行的，因此我使用 PHP 的会话处理程序。

根据我的经验，会话是最灵活的：它们通常比数据库访问更快，并且它们生成的 cookie 在浏览器关闭时（默认情况下）消失。

【讨论】：

【解决方案5】：

如果您打算将网站托管在像 webhost4life 这样便宜且愉快的主机上，请避免使用 InProc。我已经了解到，由于他们的系统被过度订阅，他们会非常频繁地回收应用程序，这会导致您的会话丢失。很烦人。

他们的建议是使用 StateServer，这很好，除非您必须序列化/反序列化会话 eash 回发。我喜欢对象，我的网络应用程序充满了它们。我担心切换到 StateServer 时的性能。我需要重构，只将我真正需要的东西放入会话中。

希望我在开始之前就知道...

干杯，罗伯。

【讨论】：

嘿，Rob，我一定会记住这一点，因为我的很多项目都将托管在“便宜又快乐”的虚拟主机上！ :)

【解决方案6】：

注意您存储客户端的状态（查询字符串、表单字段、cookie）。任何与安全相关的东西都不应该存储在客户端，除非是会话标识符，如果它被合理地模糊且难以猜测的话。有太多的网站具有像“authenticated=true”这样的设置，并将这些设置存储在 cookie 或查询字符串或隐藏表单字段中。用户绕过类似的东西是微不足道的。请记住，来自客户端的任何输入都可能被篡改并且不应被信任。

【讨论】：

【解决方案7】：

Signed Cookies 在您需要获取数据时链接到某种数据库存储。如果您有连接的后端，则没有理由在客户端存储数据；如果这是一个面向公众的网站，你只是在找麻烦。

【讨论】：

【解决方案8】：

这不是使用什么和避免什么的问题，而是什么时候使用哪个。每个人都有一个特定的情况，当它是最好的时候，和一个不同的情况，当它是最坏的时候。

决定因素通常是数据的生命周期。会话状态的寿命比表单字段长，依此类推。

【讨论】：