首页 / 知识

维持状态的方式比较

2023-04-17 08:03:00

维持状态的方式比较

comparison of ways to maintain state

在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框架都将这些工作排除在外,而对于我来说,要实现自己的状态机,我需要一个很好的理由...否则,我很可能会造成安全漏洞和功能破坏在任何成熟的框架中都会逐渐淘汰。

    因此,我想我真的无法想象除了最琐碎的原因之外,什么都不想使用基于会话的状态。


    安全也是一个问题。用户可以随意更改查询字符串或表单字段中的值。用户身份验证应保存在加密的或篡改的cookie或服务器端会话中。当用户完成表单时,跟踪表单中传递的值很可能可以将其保留在隐藏的表单字段中。

    但是,关于查询字符串的妙处(有时是危险的)是,单击链接的任何人都可以获取状态。如上所述,如果它给用户一些他们不应该拥有的授权,这将很危险。不过,很高兴向您的朋友展示您在网站上找到的内容。


    随着Web 2.0的使用不断增加,我认为您的列表中缺少两种重要的方法:

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

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

    至于哪一个最好,我认为它们都有自己的位置,但是Query String方法对于搜索引擎来说是有问题的。


    当您需要获取数据时,已签名的Cookie链接到某种数据库存储。如果有连接的后端,则没有理由在客户端存储数据;如果这是一个面向公众的网站,那么您只是在寻找麻烦。


    请注意您存储客户端的什么状态(查询字符串,表单字段,cookie)。任何与安全性相关的内容都不应存储在客户端,除非会话标识符被合理地掩盖且难以猜测,否则可能除外。太多的网站都设有" authenticated = true"之类的设置,并将其存储在Cookie或查询字符串或隐藏的表单字段中。用户绕过类似的东西是微不足道的。请记住,来自客户端的任何输入都可能被篡改,因此不应被信任。


    如果计划将网站托管在诸如webhost4life之类的价格便宜的主机上,请避免使用InProc。我已经学到了很难的方法,因为他们的系统被过度订阅,所以他们非常频繁地回收应用程序,这会使您的会话丢失。很烦人。

    他们的建议是使用StateServer,这很好,除了必须序列化/反序列化回传的会话eash。我喜欢物体,我的Web应用程序充满了物体。我担心切换到StateServer时的性能。我需要重构,只将我真正需要的东西放在会议中。

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

    干杯,罗布。


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

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


    使用什么和避免什么不是什么问题,而是什么时候使用。每种情况在最佳情况下都有其特定的情况,而在最坏情况下则具有不同的情况。

    决定因素通常是数据的生存期。会话状态的寿命比表单字段的寿命长,等等。


    状态方法服务器用户

    最新内容

    相关内容

    猜你喜欢