除了cookie之外，还能用什么方法做验证码功能？

Question

如题，一般现在的短信验证码是这样做的（至少我们是这样做的）：前端调发短信接口，response返回一个cookie，然后下一个验证的接口，前端通过设置credentials: 'include'，把cookie带上传给服务器，这样服务器就知道要对上哪个验证码了。

但是现在cookie有了个新敌人：SameSite，使得传递cookie变得困难起来，而且SameSite的兼容性也是个问题，据说部分旧版和国内的浏览器不能正确地识别SameSite=None，使得服务器端设了也白设。另外SameSite=None确实也有cors的风险。

所以我们如果不用cookie，还能怎么样实现验证码功能呢？

Answer 1

前端调用发送验证码的接口，该接口给用户手机号发送验证码，同时将这个验证码保存到redis，可以设置一分钟或者五分钟的有效期，不需要将验证码返回给前端

用户手机短信收到验证码后，自己输入验证码，调用验证接口，用户输入的验证码与刚刚redis保存的验证码进行校验和对比即可

Answer 2

你说的方案也可以.因为验证码无非就是后端生成验证码的时候,再生成一个凭据返回给用户,用户拿凭据和验证码给后端来验证验证码是否正确,至于这个凭据放到哪里,无所谓的,只要你能让用户带回来就好.
一般有状态的话就放在服务端 session 中,这是最保险的.也可以返回给前端,让前端自行保存,这样的话,这个凭据就必须是足够随机的.

Answer 3

前端调用验证码接口，验证码接口里带上账号信息，该接口不返回数据，后端保存账号和对应的验证码

收到验证码后，连验证码带账号一起提交，由后端验证合法性、时效性等

Answer 4

把放在cookie里的字段，直接放在response里，让前端暂存起来，调验证的接口时，再带上去，这样可以吗？

Answer 5

前端调用，服务端根据该接口的类型 向数据库插入一条数据，比如：
注册，手机号

insert code ( type = register and mobile = 10086 and code = 1111 )

查询的时候

select * from code where mobile = 10086 & type = register .

验证时间，code是否相同，手机号和类型 作为联合唯一键，

为了避免同一手机号 发送了过多短信，可以加个限制比如一天最多10条。

无需响应cookie，