验证码重发前端倒计时。
验证码防刷后端校验:用户请求验证码时,将请求的IP和手机号码存入Redis,并对发送频率做限制,例如每分钟/单个IP/单个手机号仅能请求一次。如果脚本无法获取用户的真实IP,直接过滤这类请求。 再加上图像验证码,输入验证码后才能发送短信
校验错误返回给前端注册页。并重定向回注册页面。(利用的Session原理,将数据放到Session中,只要跳到下一个页面取出数据后,session中数据就会删掉)【由于这里用到了Session, 所以必须解决分布式Session问题】
用过验证码必须把验证码删除(令牌机制)。
没有错误后调用用户中心远程服务进行注册,(用户名和手机号不能被占用)。
使用异常机制,用户名和手机号不能被占用,如果查询到占用,抛出对应异常。
密码不能明文保存,MD5 & MD5盐值加密(Spring 家的密码加密器)
数据库通过用户名查询到对应密码, 然后对比密码。
面试问题:如果用户很多,登录查数据库很慢怎么办? —> 数据库索引方面
为了简化自我网站的登录和注册逻辑,引入社交登录
OAuth2.0流程:
具体实现流程,以微博登录为例:
先申请微博网站接入接口,得到App Key(即client_id )
Session存在于服务器的内存中,服务器创建好Session后,命令浏览器保存sessionId到cookie中,浏览器每次访问都会带上cookie。
1.session不能跨不同域名共享,不同服务不能共享。 (不同域名附带不同的cookie)
2.同一服务,集群环境,session不能共享。
Session复制, 同一服务在不同主机上,同步复制Session。
优点:Tomcat原生支持,只需要修改配置文件。
缺点:session同步需要数据传输,占用大量带宽,每个服务都存大量session,大型分布式集群情况下,不可能用。
客户端存储。 优点是服务器不需要存储session,缺点是:都是缺点,危险,占带宽,存信息有限,可能被篡改
不会去用这种方式。
让同一个 ip 负载均衡到同一个服务器中, 优点,只需要改nginx,不需要修改应用代码,支持水平扩展。
缺点是:服务器闪断需重新登录,rehash可能会导致一部分用户路由不到正确的session
优点:没有安全隐患、可以水平扩展。服务器重启闪断都不会导致session丢失
缺点:增加一次网络调用,并且需要修改获取session的方法, 从redis取数据比内存中慢得多。
最终选择统一存储。
统一存储,登录后将session存到redis中,并把放大cookie的作用域,使子域名父域名共享sessionId, 服务通过sessionId去Redis中取Session
整合Spring Sessioin
导入依赖—配置选择使用redis–设置session过期时间—配置redis访问—注解加上RedisSession
最好使用Json的序列化方式
改变cookie作用域,写个配置文件类
SpringSession源码… 主要用了装饰者模式
单点登录就是在多个系统中,用户只需一次登录,各个系统即可感知该用户已经登录。
使用SpringSession 达到了一个系统,多个微服务和子域共享Session的目的。
但是如果是多系统。同一个公司的不同系统,域名不同,也希望一个系统登陆,访问另一个系统也能是登录状态。
比如登录了微博,我们访问新浪网,也是登录的
核心: 三个系统即使域名不一样,想办法给三个系统同步同一个用户的票据
关键核心:
session在服务器内存,或者redis里面,可以通过sessionId找到session来保持登录状态,所以客户端得保持这个sessionId,以便交互的时候返回给服务器。可以使用cookie,这样每次交互会自动被带上。核心是与服务器交互的时候带上sessionId。还有以下方法:
或者直接放弃session, 用Token (JWT) , 前端每次请求都带上token, 服务端解析token证明用户是合法的。JWT出现以后,使得单点登录更为简单了。
见上文
所有系统都去访问同一个的SSO系统【缺点SSO压力大】
谢谢你们的点赞、收藏、关注。让我们一起进步,不断创作更优秀的文章
转载请注明地址:https://blog.csdn.net/weixin_44179010/article/details/124264393