app*_*tio 13 authentication session caching scalability load-balancing
我正在尝试理解为可以在任意数量的Web服务器上运行的应用程序创建身份验证机制时的选项.到目前为止,我只对使用(网络)服务器端会话管理身份验证方面的小型网站有经验.但是,只要我想添加更多Web服务器(或PaaS环境中的"Web实例"),这种方法显然就成了一个问题; 绑定到特定计算机的身份验证状态来自我的理解,而不是您在使用负载平衡时所需要的(afaik粘性会话/粘性负载平衡是应该避免的).我正在寻找一种解决方案,允许我动态地上下调整Web服务器/实例的数量,而无需考虑身份验证机制.
我认为实现这一目标的唯一方法是从我的Web服务器中获取会话/身份验证状态.这就是我所说的"无国籍".当然,该状态必须暂时存储在某个地方,因此必须有一些不是无状态的东西.
我可以使用数据库服务器来管理所有auth会话.可以从每个http请求上的所有Web服务器访问数据库服务器,以请求用户的身份验证状态.但是,由于数据库服务器甚至比Web服务器更难扩展(这是我没有任何经验的假设),我只是将问题从Web服务器转移到数据库服务器.除此之外,我认为这不是性能方面的最佳解决方案.
我可以使用像memcached或redis这样的缓存服务器来管理会话以进行身份验证,而不是数据库服务器.我认为这会最小化可伸缩性问题,因为单个缓存服务器可以以高效的方式管理大量会话(或者我现在错了吗？).但我有时会读到诸如"关于缓存的一个重要观点是它的行为就像缓存一样:你刚刚存储的数据可能会丢失." 嗯,这将是一个问题.我不希望用户每2小时登录一次.我的问题是:如果缓存有足够的内存,为什么缓存中的数据会丢失？高速缓存服务器中的250MB内存是否足以同时管理超过一百万个会话而无需摆脱数据(当使用简单的键值对将会话ID映射到用户ID或反之)？
第三种解决方案可能是将auth sesson状态存储在由服务器签名且不能由客户端操纵的cookie中.但如果我没有错,服务器端就无法强制注销某个用户......
总结我的要求:
我想在负载均衡器上上下调整Web服务器,auth系统应该处理它
应允许用户登录至少几天
,例如在stackoverflow.com上
我对最佳实践感兴趣.我认为有很多网站面临同样的问题并找到了解决方案.
这个github项目是一个很好的起点.实施在Play中!框架,但它是我认为你所追求的一个很好的解释.还有助于克服应用程序中固有的CSRF.
服务器在登录后发回auth_token(通过https).auth_token保存为cookie(只是因为它将被保留并可从客户端访问).发出请求时,auth_token被放置为保存在cookie中的HTTP标头(通过JavaScript).然后由服务器请求处理程序拉出并通过每个请求进行验证.所以它是一个cookie - 但不是用作cookie.如果你愿意,可以使用"两次烘焙"的cookie :)链接详细说明.
关于堆栈溢出的另一个答案我发现解释了一个非常相似的事情."没有会话的会话".
然后,如果你真的想深入研究它,请查看owasp.org上的CSRF预防,它解释了" 一般建议:同步器令牌模式 " 标题下的类似技术.
所有通信都应该是HTTPS.