技术培训,临清房产网,漫画99770
在本号的一系列spring security文章中,先后介绍了各种登录验证及授权中的知识点,如:spring-security简介并与shiro对比、 formlogin模式登录认证、动态数据登录验证与权限分配、账户多次登录失败锁定、rememberme记住我功能,等等文章。笔者觉得以上的这些实际上都很简单,我们没有涉及到分布式应用。本节将以分布式的应用背景,讲解验证码实现的多种方式。本小节先从理论的角度为大家讲解,具体实现笔者还会再写。
验证码实际上和谜语有点像,分为谜面和谜底。谜面通常是图片,谜底通常为文字。谜面用于展现,谜底用于校验。
总之,不管什么形式的谜面,最后用户的输入内容要和谜底进行验证。
图中蓝色为服务端、澄粉色为客户端。
这是一种最典型的验证码实现方式,实现方式也比较简单。
这种实现方式的优点就是比较简单,缺点就是:因为一套应用部署一个session,当我们把应用部署多套如:a、b、c,他们各自有一个session并且不共享。导致的结果就是验证码和图片由a生成,但是验证请求发送到了b,这样就不可能验证通过。
在第二小节讲到的问题,实际上不是验证码的问题,而是如何保证session唯一性或共享性的问题。主要的解决方案有两种:
可能出于主机资源的考虑,可能出于系统架构的考量,有些应用是无状态的。
那么对于这些无状态的应用,我们就无法使用session,或者换个说法从团队开发规范上就不让使用session。那么我们的验证码该怎么做?
这种做法的缺陷是显而易见的:实际上就是将验证码文字在客户端服务端之间走了一遍。虽然是加密后的验证码文字,但是有加密就必须有解密,否则无法验证。所以更为稳妥的做法是为每一个用户生成密钥,并将密钥保存到数据库里面,在对应的阶段内调用密钥进行加密或者解密。
从密码学的角度讲,没有一种对称的加密算法是绝对安全的。所以更重要的是保护好你的密钥。正如没有一把锁头是绝对安全的,更重要的是保护好你的钥匙。
如对本文有疑问,请在下面进行留言讨论,广大热心网友会与你互动!! 点击进行留言回复
浅析我对 String、StringBuilder、StringBuffer 的理解
使用IDEA搭建SSM框架的详细教程(spring + springMVC +MyBatis)
Springboot整合freemarker 404问题解决方案
引入mybatis-plus报 Invalid bound statement错误问题的解决方法
网友评论