从体系结构的角度来看,什么是最佳方法会话[]或加密cookie?

这里有两个问题。首先是cookie和会话之间的区别。除非您使用无cookie会话(如URL中的唯一ID),否则会话只是一个期限很短的cookie。通过使用状态服务器,您可以轻松配置应用程序以在多个服务器之间共享会话。( ScaleOut , Velocity , SQL Server )

当然,假设您使用用户的cookie只存储一个唯一的ID,并将其链接回服务器上的所有真实数据,可能是数据库中的所有数据。然而:

在用户的cookie中存储敏感数据,即使是加密的,也不是真正的 那个 安全,因为它必须是可解密的,这意味着它是易受攻击的。每当您选择在应用程序中使用双向加密时,您将承担更重的加密负担,以维持相同的安全级别。如果你没有足够的密码专业知识可供你使用,那么最好选择安全的方法,而不要这样做。

因此,简而言之,使用内置会话或滚动您自己的会话,无论哪种方式,都要确保您发送给客户机的唯一信息是一个不可访问的ID,您可以将其绑定到存储的数据上。 你的 结束。

Remembering a user with a cookie :

指派…与该用户关联的临时ID,如guid。由于guid在天文学上是独一无二的,而且实际上是防碰撞的,所以它们实际上也不可能从系统外部进行猜测或预测。

滚动您自己的基于cookie的会话/“记住我”功能的好处是,它可以让您更好地控制信息被持久化、分发的时间等。另一方面,它确实代表了更多的工作,其中一些工作正在重新实现用ASP.NET会话实现现成的功能。通常,我建议您使用已经存在的功能,除非您能够清楚地阐明某些驱动业务需求,而这些需求可以作为一种选择消除。

从架构的角度 你应该考虑的是 此应用程序的预期规模 . 最有可能的是,最聪明的事情就是从ASP.NET内置会话功能开始。后来, 如果你发现你真的需要它 ,然后添加:

1. 低到中的可伸缩性:使用粘性会话进行负载平衡,或基于请求IP地址进行负载平衡(仍在使用ASP.NET会话)。
2. 中高可扩展性:RAM会话存储中的共享,即共享的ASP.NET StateService,项目“Velocity”, ScaleOut SessionServer 等等。
3. 高可扩展性:一个自制的基于cookie的会话系统,在Web服务器之间是完全“无状态的”,从某种意义上说,它是基于预先共享的秘密和散列,在不查询中央会话存储的情况下进行验证。如果你走这条路线,那么你也应该考虑在cookie中存储非敏感的用户设置,以便进行扩展。

完全基于cookie的会话的好处在于它具有无限的可扩展性。每次我们得到一个新的用户,我们也会得到一台新的远程PC,它可以免费为我们存储他的会话状态。当然,我们的Web前端服务器中的散列需要一些CPU,但是前端层是无状态的,并且易于扩展。缺点是它的开发工作更多。

Ask BJ_ RN Hansen对cookies中的会话进行了概述 in these presentation slides, from around slide 16 and forward . 西奥·施罗斯纳格尔在 his book Scalable Internet Architectures . Here is a good scientific paper 如果记忆对我有用的话,做真正安全的饼干,比Ask和Theo的提议更安全。

请注意,您可能不需要像您想象的那么多的可伸缩性。 例如,只有两个前端服务器提供堆栈溢出服务,负载均衡器将流量除以用户IP地址。这使得每个前端Web服务器上的本地ASP.NET会话正常工作,只要所有Web服务器都可以运行——对于大多数具有2-5个Web服务器的站点来说,这是一个可接受且非常简单的解决方案。

有一种考虑可能会推翻上述规定。 如果发现需要共享缓存 其他数据 (SQL查询结果,可重复使用但非常昂贵的CPU计算结果),以及 你已经可以实现这样一个缓存了 ,那么将会话粘贴到这个缓存中也是有意义的。我所说的共享缓存的例子有 Memcached 微软 project "Velocity" , Shared Cache , ScaleOut StateServer 以及其他。很多网站不需要这个,但它是一个很好的解决方案。一旦项目“Velocity”发布,此解决方案可能会在价格和开发时间方面变得更容易访问,这取决于微软对“Velocity”的意图。

结论

1. 您只需要在前端Web服务器之间共享会话,还是需要在其他数据(SQL结果缓存等)中共享会话?一般来说,您需要一个共享的内存缓存吗?如果是这样的话,一般来说,您必须研究共享缓存/集群中间件。
2. 如果没有,你知道你将在什么样的规模下操作吗?如果这样做,那么应该能够决定会话数据的4个选项(从ASP.NET内置会话到cookie)中哪一个最适合您。
3. 如果您刚开始,不知道您将吸引多少用户,那么我将从ASP.NET内置会话功能开始,然后根据需要添加更复杂的解决方案。

我不明白为什么曲奇在这里受到如此恶劣的批评。我见过一些大型系统中使用的cookie方法,我从未见过它被黑客入侵。

传统方法是由sqlsessionstateprovider支持的会话。

现代的方法似乎是使用数据库进行存储,并在数据库前面使用缓存(memcached)来加速查找。但会话已退出,加密的cookie(auth cookie除外)。

是的,我怀疑你对饼干的处理可能很混乱。

我建议使用可以在任何计算机上运行的ASP.NET StateService来处理会话。

如果你走上饼干之路,你就需要非常小心地去做,除非你是专家,否则你几乎肯定会做错事。

如果用户清除浏览器上的cookie信息,则肯定会丢失。这不是会话的情况