比较维持国家的方式

在Web开发中有多种方法可以维护用户状态.

这些是我现在能想到的:

请求参数

饼干

表格方法(获取和发布)

Viewstate(我只猜ASP.NET)

会话(InProc Web服务器)

会话(专用Web服务器)

会话(数据库)

本地持久性(Google Gears)(感谢Steve Moyer)等

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

但是,在设计Web应用程序时,我总是对使用什么方法来应用什么方法或避免哪些方法感到困惑.

我想知道的是,您通常使用哪种方法,并建议或更有趣的是,您希望在某些情况下避免使用哪些方法？为什么？

虽然这是一个非常复杂的问题,但在考虑实施状态时,我会考虑一些快速的事情.

查询字符串状态仅对最基本的任务有用 - 例如,可能保持用户在向导内的位置,或者在完成给定任务(例如,登录)之后提供将用户重定向到的路径.否则,查询字符串状态非常不安全,难以实现,并且为了做到公正,它需要通过包含一个密钥将客户端绑定到该客户端的服务器维护状态来绑定到某些服务器端状态机.

Cookie状态或多或少相同 - 它比查询字符串状态更加漂亮.但它仍然完全维护在客户端,除非cookie中的数据是将客户端绑定到某个服务器端状态机的关键.

表单方法状态也是类似的 - 它对于隐藏将给定表单绑定到后端的某些数据的字段很有用(例如,"此用户正在编辑记录#512,因此表单将包含带有值的隐藏输入512" ).它对其他许多东西没用,再次,它只是查询字符串和cookie状态背后相同思想的另一种实现.

会话状态(您描述的任何方式)都很棒,因为它们是无限可扩展的,并且可以处理您选择的编程语言可以处理的任何内容.第一个需要注意的是,客户端需要有一个密钥才能将客户端与存储在服务器上的状态联系起来; 这是大多数Web框架向客户端提供基于cookie或基于字符串查询的密钥的地方.(几乎每个现代人都使用cookie,但如果没有启用cookie,则会回到查询字符串上.)第二个警告是,你需要把一些内容放到你存储状态的方式中......你会把它放在一个数据库？您的Web框架是否完全为您处理？同样,大多数现代Web框架都需要完成这项工作,而且对于我来说,实现我自己的状态机,我需要一个非常好的 有充分的理由......否则,我很可能会在任何成熟的框架中创建随着时间的推移而被破坏的安全漏洞和功能破坏.

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