分享
认证授权基础
输入“/”快速插入内容
认证授权基础
简单的来说:
•
认证(Authentication):你是谁
◦
正式:验证身份的凭据(如用户名/密码),通过这个凭据,系统知道存在你这个用户。
•
授权(Authorization):你有权限干什么
◦
在认证之后,掌管访问系统的权限,有些特定地资源只能由具有特定权限的人才能访问,如admin,有些对系统资源操作比如删除、添加、更新只能由特定人才具有
Cookie和Session
Cookie
Cookie和Session都是用来跟踪浏览器用户身份的会话方式,但两者的应用场景不太一样
Cookie存放在客户端,一般用来保存用户信息,应用案例如下:
1.
在Cookie中保存已经登陆过的用户信息,下次访问网站时可以自动帮你填写一些基本信息。除此之外,还能保存用户首选项、主题和其他设置信息
2.
使用Cookie保存SessionId或者Token,向后段发送请求时带上Cookie,这样后端就能获取Session或者Token,记录用户当前状态,毕竟HTTP协议时无状态的
3.
记录和分析用户行为。举个🌰,当你在网上购物时,服务器想要获取你在某个页面的停留状态或者看了哪些商品,一种常用的实现方式就是将这些信息存放在Cookie
Session
•
主要作用:通过服务端记录用户的状态,安全性更高
•
典型场景:当添加商品到购物车时,系统不知道是哪个用户操作的,因为HTTP协议无状态,服务端给特定的用户创建特定的Session之后,就可标识该用户并且跟踪这个用户了
Session-Cookie方案进行身份验证
通过SessionID来识别特定用户,一般将SessionID存入Redis中
1.
用户向服务器发送用户名、密码、验证码用于登陆系统
2.
服务器验证通过后,服务器为用户创建一个Session,并将Session信息存储起来
3.
服务器向用户返回一个SessionID,写入用户的Cookie
4.
当用户保持登陆状态时,Cookie将和每个后续请求一起被发送出去
5.
服务器可以将存储在Cookie上的SessionID与存储在内存中或者数据库中的Session信息进行比较,以验证用户身份,返回给用户客户端响应信息的时候会附带用户当前状态
注意
•
依赖Session的关键义务一定要确保客户端开启了Cookie
•
注意Session的过期时间
Spring Session提供了一种跨多个应用程序或实例管理用户会话信息的机制。
多服务节点下的Session-Cookie方案
当服务器水平拓展成多节点时,将面临挑战:
•
举个🌰:部署两份相同的服务A、B,用户第一次登陆时,Nginx通过负载均衡机制将用户请求转发到A服务器,此时用户的Session信息保存在A服务器。结果,用户第二次访问时Nginx将请求路由到B服务器,由于B服务器没有保存用户Session信息,将导致用户需要重新进行登陆
参考的几个解决方案:
1.
某个用户的所有请求都通过特性的哈希策略分配给同一个服务器处理。这样的话,每个服务器都保存了一部分用户的Session信息。服务器宕机,其保存的所有Session信息就完全丢失
2.
每一个服务器保存的Session信息都是互相同步,每一个服务器都保存了全量的Session信息。每当一个服务器的Session信息发生变化,我们需要将其同步到其他服务器,此方案成本太大,并且节点越多时同步成本越高
3.
单独使用一个所有服务器都能访问到的数据节点(如缓存)来存放Session信息,为保证高可用,数据节点尽量要避免是单点
4.
Spring Session是一个用于在多个服务器之间管理会话的项目,它可以与多种后端存储集成,从而实现分布式会话管理。通过Spring Session,可以将会话数据存储在共享的外部存储中,以实现跨服务的会话同步和共享。
防止CSRF攻击
CSRF(Cross Site Request Forgert)跨站请求伪造