In a series of articles in this Spring Security numbers in, we have introduced a variety of login authentication and authorization of knowledge, such as: spring-security profile and the shiro contrast, formLogin login authentication mode, dynamic data entry validation and permission assignments, account repeated login failures locks, RememberMe Remember me features, and more articles. I think more of these are actually very simple, we do not relate to distributed applications. This section will be distributed application background, to explain the verification code implemented in a variety of ways. This section first from a theoretical perspective for you on the specific implementation I will write.
- stores session authentication code is not suitable for distributed applications
- Code sharing session storage for distributed applications
- Symmetric algorithm based on the verification code for distributed applications
A verification code part
Verification code and actually a bit like a riddle, riddle and mystery divided. Riddle is usually an image, the answer is usually text. Riddle for the show, the answer for verification purposes.
- For character codes. For example: riddle is a string "ABGH" picture, the answer is the string "ABGH"
- For the calculation of the class codes. For example: riddle is "1 + 1 =" pictures, the answer is "2"
- For drag type codes. For example: riddle is a drag and drop puzzle, the answer is the coordinate position of the puzzle
In short, no matter what form of riddle, enter the contents of the last user to verify and answers.
Two, session codes stored
The blue is the service side, Cheng pink for the client.
This is the most typical implementation of codes, relatively simple implementation.
- Application server generates a random character codes
- The character codes stored inside the session
- The codes generated character image codes in response to the client
- Check that the contents of the user input verification code consistent answers
The advantage of this implementation is relatively simple, the disadvantage is: a set of application deployment because a session, when we deploy the application, such as multiple sets: A, B, C, and they each have a session is not shared. The result is the image generated by the authentication code and the A, and sent to the verification request to B, so that it is possible to verify through.
Third, the shared session codes stored
In the second section mentioned problem, the problem is not actually verification code, but rather how to ensure the uniqueness of the problem or sharing the session. There are two main solutions:
- 通常我们实现负载均衡应用的前端都是使用nginx或者haproxy，二者都可以配置负载均衡策略。其中一种策略就是：你的客户端ip上一次请求的是A应用，你的下一次请求还转发给A应用。这样就保证了session的唯一性。但是这种方式有可能会导致A、B、C应用其中一个或两个分配了大量的请求，而另外一个处理很少的请求，导致负载并不均衡。
- 另外一种非常通用的方式就是将分布式应用的session统一管理，也就是说原来A、B、C各自的session都存在自己的内存中，现在更改为统一存储到一个地方，大家一起用。这样就实现了session的唯一和共享，是实现分布式应用session管理的有效途径。在Spring框架内，最成熟的解决方案就是spring session + redis 。可自行参考实现。
四、基于对称算法的验证码
可能出于主机资源的考虑，可能出于系统架构的考量，有些应用是无状态的。
- 什么是无状态应用：就是不保存用户状态的应用。
- 什么是用户状态：比如当你登陆之后，在session中保存的用户的名称、组织等等信息。
- 所以可以简单的理解，无状态应用就是无session应用。当然这并不完全准确。
那么对于这些无状态的应用，我们就无法使用session，或者换个说法从团队开发规范上就不让使用session。那么我们的验证码该怎么做？
- 同样，首先要生成随机的验证码（谜底），但是不做任何存储操作
- 将谜底（验证码文字）加上时间串、应用信息等组成一个字符串进行加密。必须是对称加密，也就是说可以解密的加密算法。
- 生成验证码图片，并与加密后的密文，通过cookies一并返回给客户端。
- 当用户输入验证码提交登录之后，服务端解密cookies中的密文（主要是验证码文字），与用户的输入进行验证比对。
这种做法的缺陷是显而易见的：实际上就是将验证码文字在客户端服务端之间走了一遍。虽然是加密后的验证码文字，但是有加密就必须有解密，否则无法验证。所以更为稳妥的做法是为每一个用户生成密钥，并将密钥保存到数据库里面，在对应的阶段内调用密钥进行加密或者解密。
Speaking from the perspective of cryptography, encryption algorithm is not a symmetrical is absolutely safe. It is more important is to protect your key. Just as no one is absolutely safe lock, more importantly, protect your keys.
Look forward to your attention
- Bloggers to recommend a series of documents: "Hands touch hands teaches you SpringBoot series chapter 97 section -16"
- This article is reproduced indicate the source (en must not turn only the text): letters Gebo off .