只是为我即将建立的Web应用程序集思广益.
Web的基石之一是会话处理:让用户登录,发送带有魔术二进制编码的小精灵粉尘的cookie,然后盲目地信任用户.
我只是想知道完全消除通常使用它的网络应用程序的"传统"会话是否可行,例如在线商店.
我们的想法是拥有一个不使用SessionID或任何东西的"服务器端会话",而是使用用户名.所以每个用户只有1个会话,而不是更多.这将允许像持久购物车这样的东西工作.
将按照与Web服务的工作方式类似的方式处理身份验证:在每个页面视图上预期HTTP摘要身份验证.
忽略匿名访问者必须以不同方式处理的事实,您认为这种方法是否可行?或者从长远来看,用于持续认证的额外流量/负载是否会成为交易破坏者?
首先,我们根本不使用会话.
我们发现利用会话使代码复杂化而没有任何好处.甚至考虑使用会话状态只有两个原因.第一个是减少sql server的流量.但是,对于负载均衡的Web服务器等,会话必须存储在sql server中......哪种方式消除了它的第一点.但它更糟糕,因为必须在每个页面加载时检索,反序列化,序列化和存储会话.
第二个原因是不要让浏览器在每个请求上将用户ID传递回应用程序.但是,"会话劫持"是一个相当容易实现的技巧,很少被考虑在内.
因此,相反,我们使用高度加密的cookie,其中包含无法猜测的值,准确指出用户是谁.我们将这与不断变化的,不可猜测的请求ID相结合,消除了会话状态(并且它是不必要的开销),同时提高了安全性.
饼干可以被盗吗?当然,但它的生命非常有限,即两次回发之间的时间量.这意味着它会被发现相当快地受到损害.
所以,我不会说会议是网络的"基石".相反,我会说它们是经常使用不当的拐杖,出于安全和性能原因应该避免使用.
所有这一切说明,你要将这个与用户ID联系起来的唯一方法就是你强迫你的用户在购物之前登录/创建帐户.除非他们别无选择,否则没有人会做在您的网站上.
哦,不要相信我的话:
4GuysFromRolla.com - >会话变量是邪恶的.
aps.net - >会话变量还是邪恶的?
斯科特·汉斯曼(Scott Hansleman) - >将视图状态移动到会话中 注意大胆覆盖内存消耗的部分,并且能够长时间保持这种状态.
编码恐怖 - >你的会话超时了 这详细说明了与使用会话
维基百科相关的一些问题- >会话劫持 什么列表是完整的,没有维基百科的链接?