前期做网站宣传费用怎样做账,wordpress用什么php版本,成都金铭 网站建设,怎么查看域名网站的容量到期在黑客新闻#xff0c;reddit和博客上#xff0c;该主题已经讨论了很多次。 共识是–请勿使用JWT#xff08;用于用户会话#xff09;。 而且我在很大程度上同意对JWT的典型论点 #xff0c; 典型的“但我可以使其工作……”的解释以及JWT标准的缺陷的批评 。 。 我不会… 在黑客新闻reddit和博客上该主题已经讨论了很多次。 共识是–请勿使用JWT用于用户会话。 而且我在很大程度上同意对JWT的典型论点 典型的“但我可以使其工作……”的解释以及JWT标准的缺陷的批评 。 。 我不会在这里重复所有内容因此请阅读这些文章。 您真的可以使用JWT付诸实践了解它很复杂并且对于大多数用例来说几乎没有好处。 我猜对于API调用是有意义的特别是如果您在单页应用程序中为RESTful客户端重用相同的API那么我将重点讨论用户会话用例。 受到所有这些批评之后我违背了以上文章的建议使用了JWT浏览了他们的论点并声称我处于最佳状态。 我很可能是错的。 我将用户ID存储在作为cookie存储的JWT令牌中。 不是本地存储因为这是有问题的。 不是整个状态因为我不需要那可能导致问题在链接的文章中指出。 我想避免在设置中跨节点共享会话。 这是不使用Web服务器/框架的会话机制的非常令人信服的原因。 不您不需要拥有数百万个用户即可要求您的应用程序在多个节点上运行。 实际上它应该几乎总是在至少两个节点上运行因为节点会死掉并且您不希望停机。 负载平衡器上的粘性会话是解决该问题的一种方法但是您只是将集中式会话存储外包给了负载平衡器有些负载平衡器可能不支持它。 共享的会话缓存例如memcachedelasticachehazelcast也是一种选择许多Web服务器至少在Java中支持可插入的会话复制机制但是这为体系结构引入了另一个组件要支持的堆栈的另一部分以及可能会破裂。 它不一定很坏但是如果有一种简单的方法可以避免它那我就去做。 为了避免共享会话存储您需要在请求/响应周期中传递整个会话状态作为cookie请求参数标头或者需要接收userId并从数据库或缓存中加载用户。 据我们了解前者可能是一个错误的选择。 尽管有诸如ASP.NET和JSF之类的框架将整个状态转储到页面HTML中的事实但这听起来并不好。 至于后者–您可能会说“好吧如果您打算在每个请求中从数据库中加载用户这将会很慢并且如果您使用缓存那么为什么不对会话本身使用缓存呢” 。 好吧缓存可以是本地的。 记住我们只有几个应用程序节点。 每个节点可以为当前活动的用户提供一个本地内存缓存。 所有节点都将加载相同的用户在负载均衡器以循环方式将一些请求路由到它们之后的事实并不重要因为该缓存很小。 但是您不必在节点之间复制它也不必照顾从群集来来回去的新节点处理节点之间的网络问题等等。每个应用程序节点都是孤岛应用程序节点。 因此这里是我对链接文章的第一个反对意见–仅将用户标识符存储在JWT令牌中并不是没有意义的因为它可以使您免于会话复制。 对JWT标准及其加密的安全性的批评又如何呢 完全正确很容易用脚射击。 这就是为什么我仅将JWT与MAC一起使用并且仅将其与接收令牌时经过验证的特定算法一起使用从而有选择地避免了所有陷阱。 公平地说我愿意使用其中一篇文章中提出的替代方案PASETO 但是它没有Java库实现它需要花费一些时间将来可能会这样做。 总结一下–如果存在另一种易于使用的经过身份验证的cookie加密方法我会使用它。 因此我基本上是在“ PASETO模式”下使用JWT它只有一种操作和一种算法。 作为一般方法这应该很好-本文没有批评在令牌和无状态应用程序节点中包含用户标识符的想法而是批评了标准的复杂性和脆弱性。 这是我的第二个反对意见–“不使用JWT”被广泛理解为“不使用令牌”而事实并非如此。 我在为简化体系结构和缺乏共享状态而努力时是否引入了一些漏洞 我希望不是。 翻译自: https://www.javacodegeeks.com/2018/03/using-jwt-sessions.html
