维持状态的方式比较 [英] comparison of ways to maintain state

问题描述

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

There are various ways to maintain user state using in web development.

这些是我现在能想到的:

These are the ones that I can think of right now:

1. 查询字符串

1. Query String

饼干

表单方法(获取和发布)

Form Methods (Get and Post)

Viewstate(我猜只有ASP.NET)

Viewstate (ASP.NET only I guess)

会话(InProc Web服务器)

Session (InProc Web server)

会话(专用网络服务器)

Session (Dedicated web server)

会话(数据库)

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

Local Persistence (Google Gears) (thanks Steve Moyer) etc.

我知道每种方法都有其自身的优点和缺点，例如cookie不安全以及QueryString具有长度限制并且很难看！ ;)

I know that each method has its own advantages and disadvantages like cookies not being secure and QueryString having a length limit and being plain ugly to look at! ;)

但是，在设计Web应用程序时，我总是对在哪种应用程序中使用哪种方法或避免使用哪种方法感到困惑.

But, when designing a web application I am always confused as to what methods to use for what application or what methods to avoid.

我想知道的是，您通常使用哪种方法，或者更有趣地建议您在某些情况下要避免使用哪种方法?为什么?

What I would like to know is what method(s) do you generally use and would recommend or more interestingly which of these methods would you like to avoid in certain scenarios and why?

推荐答案

尽管这是一个非常复杂的问题，但在考虑实现状态时，我想到了一些简短的内容.

While this is a very complicated question to answer, I have a few quick-bite things I think about when considering implementing state.

• 查询字符串状态仅对最基本的任务有用-例如，维护用户在向导中的位置，或者提供在用户完成给定任务后将其重定向到的路径(例如，登录) ).否则，查询字符串状态非常不安全，难以实现，并且为了做到合理，它需要通过包含将客户端绑定到该客户端的服务器维护状态的键来绑定到某些服务器端状态机.
• Cookie状态大致相同-它比查询字符串状态更奇特.但是，除非cookie中的数据是将客户端绑定到某些服务器端状态机的关键，否则它仍将完全保留在客户端上.
• Form方法的状态再次相似-对于隐藏将给定表单与后端的某些数据相关联的字段很有用(例如，此用户正在编辑记录#512，因此表单将包含隐藏的输入值512).它对其他方面没有多大用处，同样，它只是查询字符串和cookie状态背后相同想法的另一种实现方式.
• 会话状态(您描述的任何一种方式)都很棒，因为它们是无限可扩展的，并且可以处理您选择的编程语言可以处理的任何事情.首先要注意的是，客户端必须有一把钥匙才能使该客户端与存储在服务器上的状态保持一致.这是大多数Web框架向客户端提供基于cookie或基于查询字符串的密钥的地方. (几乎每个现代的人都使用cookie，但是如果未启用cookie，则会使用查询字符串.)第二个警告是，您需要在存储状态的方式中放一些……将它放入一个数据库?您的Web框架是否完全为您处理?再说一次，大多数现代的Web框架都将其排除在外，而对于我来说，要实现自己的状态机，我需要一个非常的充分理由...否则，我很可能会创建安全性在任何成熟的框架中，随着时间的流逝而产生的漏洞和功能破坏.

• Query string state is only useful for the most basic tasks -- e.g., maintaining the position of a user within a wizard, perhaps, or providing a path to redirect the user to after they complete a given task (e.g., logging in). Otherwise, query string state is horribly insecure, difficult to implement, and in order to do it justice, it needs to be tied to some server-side state machine by containing a key to tie the client to the server's maintained state for that client.
• Cookie state is more or less the same -- it's just fancier than query string state. But it's still totally maintained on the client side unless the data in the cookie is a key to tie the client to some server-side state machine.
• Form method state is again similar -- it's useful for hiding fields that tie a given form to some bit of data on the back end (e.g., "this user is editing record #512, so the form will contain a hidden input with the value 512"). It's not useful for much else, and again, is just another implementation of the same idea behind query string and cookie state.
• Session state (any of the ways you describe) are all great, since they're infinitely extensible and can handle anything your chosen programming language can handle. The first caveat is that there needs to be a key in the client's hand to tie that client to its state being stored on the server; this is where most web frameworks provide either a cookie-based or query string-based key back to the client. (Almost every modern one uses cookies, but falls back on query strings if cookies aren't enabled.) The second caveat is that you need to put some though into how you're storing your state... will you put it in a database? Does your web framework handle it entirely for you? Again, most modern web frameworks take the work out of this, and for me to go about implementing my own state machine, I need a very good reason... otherwise, I'm likely to create security holes and functionality breakage that's been hashed out over time in any of the mature frameworks.

所以我想我真的无法想象除了最琐碎的原因之外，什么都不愿意使用基于会话的状态.

So I guess I can't really imagine not wanting to use session-based state for anything but the most trivial reason.

这篇关于维持状态的方式比较的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！