The front-end user fills in the value of the CAPTCHA image when registering, then carries on the pair with the back end.
However, because the user is not registered, unable to bind him an identity, so my temporary design is this:
When generating a captcha picture, the value of the verification code is stored in the cache (Redis), the cache sets the expiration time, and then the front-end submits a verification code to read the value from the cache, to see if there is a pair of success and delete the bar cache.
The problem is that it is possible to have a wrong or a successful situation, but the odds are not particularly high.
Is there a better idea?
Reply content:
The front-end user fills in the value of the CAPTCHA image when registering, then carries on the pair with the back end.
However, because the user is not registered, unable to bind him an identity, so my temporary design is this:
When generating a captcha picture, the value of the verification code is stored in the cache (Redis), the cache sets the expiration time, and then the front-end submits a verification code to read the value from the cache, to see if there is a pair of success and delete the bar cache.
The problem is that it is possible to have a wrong or a successful situation, but the odds are not particularly high.
Is there a better idea?
If the non-front and back ends are separated, the verification code can be stored in the session for verification.
If it is a front-end separation, then each request is stateless, then it needs to be assigned to the front-end token at the first request of the front-end, and the token will be taken with each request. The token can be used as the key value for Redis and the validation will be placed in the corresponding value position.
A session a verification code, not registered also have session
As long as the control is good, there should be no mistakes and can be a success of the situation.
1. Generate the verification code in the background. and put it in the session.
2, the front desk to obtain the verification code is also just put in the session of this synchronization.
3, if the reception is wrong, or the user clicked the switch verification code. The backstage will replace the verification code, while the session also replaced
In fact, as long as always ensure that the foreground display of the verification Code and synchronization in the session will not be the problem.
PS: Each request is multithreaded, it should not be wrong or can be a success of the situation.
When the user registers to generate the verification code, writes the verification code to the session, after the user submits, reads the verification code from the session, carries on the comparison
You refer to this article http://netsecurity.51cto.com/art/201402/428721.htm
Front:
Back end:
$showing=strtoupper($_POST['checkcode']); //检测提交过来的验证码if($_SESSION['checkcode']!=$showing||empty($showing)){ unset($_SESSION['checkcode']); die('验证码错误');}
Verification Code Generation:
Session: In a computer, especially in a network application, it is called "conversation control." Whether it is a registered user or not, the server generates a unique session ID as long as it is accessed. The verification code data can be found in the session.