场景:
前后端分离的web,采用token认证方式。后台需要生成验证码供给前端,前端返回输入的验证码之后后台进行比对。
(注:后端使用flask,flask中的session基于secure session加密写入cookie传到浏览器)
问题:
验证码需要在后台验证
方法:
将验证码设为global
结果:
暂时可用但衍生新的问题
问题II:
设为global的验证码生成方式下,前端获取到的验证码只能是本次最新,即打开两个登录页面,最新生成的验证码只有一个。
造成了验证码只能一次验证。
分析:
早期使用Session,后台返回验证码信息同时写入一个session,有一个SessionID的字段和当前这个验证码对应。所以当用户输入用户名、密码和验证码的时候,浏览器自动把存有session信息的cookie发送到服务器,服务器基于Session可以判断当前这个验证码确实是A用户应该要输入的。但目前系统采用token认证(方便集成),没有引入se
前后端分离的web,采用token认证方式。后台需要生成验证码供给前端,前端返回输入的验证码之后后台进行比对。
(注:后端使用flask,flask中的session基于secure session加密写入cookie传到浏览器)
问题:
验证码需要在后台验证
方法:
将验证码设为global
结果:
暂时可用但衍生新的问题
问题II:
设为global的验证码生成方式下,前端获取到的验证码只能是本次最新,即打开两个登录页面,最新生成的验证码只有一个。
造成了验证码只能一次验证。
分析:
早期使用Session,后台返回验证码信息同时写入一个session,有一个SessionID的字段和当前这个验证码对应。所以当用户输入用户名、密码和验证码的时候,浏览器自动把存有session信息的cookie发送到服务器,服务器基于Session可以判断当前这个验证码确实是A用户应该要输入的。但目前系统采用token认证(方便集成),没有引入se