Session
Session表示会话,是用户访问服务器的会话唯一标识,浏览器访问服务器的时候,服务器首先拿到sessionid去找有没有对应的session,服务器内存中没有的话,则创建一个session,并且把session对象的id放到cookie中,以键值对(Chrome浏览器为例)jsessionid = 1e456611sd32623dp39 存在浏览器上
1,注意:这里的 【获取id并且通过id去找session、放入cookie 】这个过程是服务器(就拿tomcate服务器为例)在拿到请求之后,tomcat服务器已经实现好的,看源码就可以了解到,并不是我们自己项目中去人为实现这一过程,当然,这个过程我们也可以重写源码中的某些接口,实现自定义sessionid,这都是没问题的,有个关键的接口之一sessionstrage接口,这个接口中就是有关实现会话,销毁,生成sessionid相关功能的接口,有兴趣的想要实现自定义session可以去看看相关源码。
2,session在服务端生成(tomcate服务器帮我们实现了),默认是放在内存中的,sessionid是唯一标识,不同的seeeionid表示不同的会话,随着访问用户增多,用户生成的seeion越来越多,此时,服务器内存中会存放很多的session对象,对内存有一定的消耗,session也可以设置失效时间
不同的seeeionid表示不同的会话:这句话怎么验证?
可以在服务器端,controller层上加上HttpServletRequest 参数,通过request.getSession()就可以得到当前会话session对象,打开不同的浏览器,访问,对比一下session对象引用地址,发现是不一样的,也就代表不同用户访问创建了不同的会话,会话是唯一的。
session是与cookie一起使用的,如果cookie被禁用了,session也就没就标识不了什么了。
Cookie
Cookie是浏览器一小块存储信息的空间,大概4kb的内存空间,不大,存储少量信息,cookie是服务器端创建并且响应给到浏览器的,cookie的使用设置的参数包括是否是否过期,存活时间、访问cookie的服务路径等
1,cookie在服务器端的创建通过有参构造函数创建,cookie中数据以键值对的形式存在。
2,cookie可以实现共享,前提是同ip的请求,不同端口、不同路径的请求访问,服务器端都可以拿到保存在cookie中的所有内容,注意,这是端口号不同,cookie也是可以共享的,举例:localhost:8080和localhost:8081两个项目下,浏览器的传入到自个儿服务器上的cookie都是一样的,cookie共享。
3,cookie容易被拦截,被进行CSRF攻击(跨站伪造请求访问服务,对服务造成不利的影响)
Token
cookie+session 是实现认证的一种非常好的方式,但是凡事都有两面性,它们实现的认证主要有以下缺点:
增加请求体积,浪费性能,因为每次请求都会携带 cookie。
增加服务端资源消耗,因为每个客户端连接进来都需要生成session,会占用服务端资源的。
容易遭受 CSRF 攻击,即跨站域请求伪造
那么为了避免这些缺点,token 方式的鉴权出现了,它可以说是一个民间的认证方式,但是不得不说它带来了非常多的好处。
Token令牌:当前项目服务处理登录认证模块最流行的一种解决方案
Token 的组成:
token 其实就是一串字符串而已,只不过它是被加密后的字符串,它通常使用 uid(用户唯一标识)、时间戳、签名以及一些其它参数加密而成。我们将 token 进行解密就可以拿到诸如 uid 这类的信息,然后通过 uid 来进行接下来的鉴权操作。
token 认证流程:
使用基于 Token 的身份验证方法,在服务端不需要存储用户的登录记录。
1.前端使用用户名跟密码请求首次登录
2.后服务端收到请求,去验证用户名与密码是否正确
3.验证成功后,服务端会根据用户id、用户名、定义好的秘钥、
过期时间生成一个 Token,再把这个 Token 发送给前端
4.前端收到 返回的Token ,把它存储起来,比如放在 Cookie 里或者 Local Storage 里
5.前端每次路由跳转,判断 localStroage 有无 token ,没有则跳转到登录页。
有则请求获取用户信息,改变登录状态
6.前端每次向服务端请求资源的时候需要在请求头里携带服务端签发的Token
7.服务端收到请求,然后去验证前端请求里面带着的 Token。没有或者 token 过期,
返回401。如果验证成功,就向前端返回请求的数据。
8.前端得到 401 状态码,重定向到登录页面。
以下几点特性会让你在程序中使用基于Token的身份验证
1.无状态、可扩展
2.支持移动设备
3.跨程序调用
4.安全
Session与Token对比:
session的安全性远远弱于token,token中通过安全性高得加密算法并且签名,token中存储得也只是用户的userid信息,而session存储得是用户得全部信息,这种信息爆光程度,token小的多,就算token被拦截,并且被破解加密了,里面存储得用户id信息基本没有什么用处。
token在实际开发中,处理单点登录的一种token为: JWT
JWT 本质是一种安全性高的加密字符串。
了解jwt链接: https://blog.csdn.net/qq_45399396/article/details/121721822
总结
虽然前面解释 cookie、session、token 的目的都是一样的:鉴权和认证。
session 是空间换时间,token 是时间换空间
鉴权认证方式 | 特点 | 优点 | 缺点 |
---|---|---|---|
session | 1.存储在服务端。2.存储大小无限制。 | 1.查询速度快,因为是个会话,相当于是在内存中操作。2.结合 cookie 后很容易实现鉴权。3.安全,因为存储在服务端。 | 1.耗费服务器资源,因为每个客户端都会创建 session。2.占据存储空间,session 相当于存储了一个完整的用户信息。 |
cookie | 1.存储在客户端。2.请求自动携带 cookie。3.存储大小 4KB。 | 1.兼容性好,因为是比较老的技术。2.很容易实现,因为 cookie 会自动携带和存储。 | 1.需要单独解决跨域携带问题,比如多台服务器如何共享 cookie。2.会遭受 CSRF 攻击。3.存储在客户端,不够安全。 |
token | 1.体积很小。2.自由操作存储在哪里。 | 1.安全,因为 token 一般只有用户 id,就算被截取了也没什么用。2.无需消耗服务器内存资源,它相当于只存了用户 id,session 相当于存储了用户的所有信息。3.跨域处理较为方便,比如多台服务器之间可以共用一个 token。 | 1.查询速度稍微慢,因为 token 只存了用户 id,每次需要去查询数据库。(解决方式:将第一次登录查询的用户信息保存到redis缓存中,这样子之后直接查询redis缓存要快的多的多!) |