首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Spring Security入门到实践(二)表单认证实践及原理分析

    登录认证功能是我们在日常生活中使用到最多的功能之一,现在互联网应用基本都具备表单登录能力,基本的思路都是当用户访问一个需要登录后才能访问的功能,应用会提示用户没有登录,从而跳转到登录页面进行登录,登录成功之后,会自动跳转回原来访问的功能或者资源。对于现在前后端分离的应用而言,一般用户登录成功之后跳转到原来的页面还是进入到用户个人中心,一般都是由前端来决定,前端发起登录请求,后端校验用户提供的用户名和密码,如果正确,前端将拿到后端提供的用户认证信息和权限列表,由前端根据用户信息来决定下一步该如何进行。

    02

    Curator学习笔记(二)- 防重复提交

    上一篇文章中我们大概了解了Curator做读写锁的原理和过程。根据了解,我们可以使用curator的读写锁来做一个分布式防重复提交的策略。为什么采用curator来做这个事情的原因是curator提供的读写锁能够跨线程和jvm进行加锁。如果不加锁,那么因为网络抖动或者线程切换,谁都不知道防重复提交的token标志是否被其他请求修改。因此这块必然要采用加锁的方式。通过锁的创建和删除来保持多个重复请求的有序性,在保证有序性之后,我们就可以按照逻辑对token进行修改,这样其他线程就能够判断自身是否为重复请求。除此之外,在加锁的时候我们采用临时znode,在会话结束之后就可以自动销毁。因此可以避免zk服务端被累计打满的情况。当然这块的会话时间是可以根据业务需求设置的。对于放重复提交的一般规则来说,我无非就是将session提取出来,而session则是和用户绑定的,因此这块我们将userId作为放重复提交的判断标志,将token表示该用户下次提交的表单的有效token,因此同一时刻,只允许同一用户提交一个表单,否则就会因为抢占token,而导致后一表单提交被认定为重复的提交(这块需要优化,下一个版本再优化!)。

    01
    领券