Web会话管理

最新推荐文章于 2023-05-01 18:36:13 发布

Lawliet-zhang

最新推荐文章于 2023-05-01 18:36:13 发布

阅读量212

点赞数

分类专栏： Java Web开发文章标签： web 会话 Java

本文链接：https://blog.csdn.net/meiyouyaCSDN/article/details/99991431

版权

5 篇文章 0 订阅

订阅专栏

4 篇文章 0 订阅

订阅专栏

Web应用通常使用的是HTTP请求，但是HTTP是无状态的，一次请求结束，连接就会自动断开，服务器只能知道每个请求的来源地址，可是这对会话的管理毫无意义。根本无法对用户进行认证和权限控制。于是，就有了相应的方案来解决这问题。常用的方法有三个：

基于server端的session来管理

在早期的Web应用中，基本上采用的都是此种方式来进行会话管理。session是服务端创建的一个全局对象，在这个对象中存储用户的登录信息，就可以达到会话管理的目的。

主要问题：

用户第一次访问应用是，服务端会创建session对象，可以在session中存储用户的信息，从而进行会话管理。每个session有个唯一的sessionId，会写回到客户端的cookie中，每次服务器从cookie中读取id并通过id获取session，但是当用户量过大时，服务器压力会特别大
session是由服务器创建的，在集群是，其本身并不具备共享的特性
如果多个应用共用一个session，就会存在跨域的问题

后来用redis来存储session，成功避免了服务器的压力。共享也可以通过redis实现，但是，由于session的传递依赖sessionId，而sessionId依赖cookie，所以cookie就出现了跨域的问题。

由于这种方式，在用户量上升之后，会大幅度的提升服务器压力以及架构复杂性。所以，很快就被淘汰了。

为了减小服务器的压力和架构复杂性，于是就想到了把用户的登录信息放在客户端来解决这个问题。cookie正好可以实现这个功能。把登录凭证放在cookie中并设置有效期，每次登录就验证cookie中登录凭证即可。

用户发起登陆请求，请求参数包括用户名（也可以是邮箱、手机号等）、密码，有时候还会有验证码之类的，服务端使用这些东西，创建一个凭证（一般称为ticket），这个凭证至少要包含2个值：
- ticket的标识，一般是一串能够绝对保证唯一的字符串，如UUID，安全点的，UUID+时间戳，甚至加上随机数的，这个取决于用户的量级，越大的量级就需要越复杂的算法，从而保证ticket的绝对唯一
- ticket的过期时间，用于验证ticket是否有效，一般这个值存的不是它在什么时候到期，而是在多久之后到期，所以，一般还会返回一个ticket的创建时间，两个值一起，确定ticket是否有效，懒得话也可以直接存到期时间的时间戳
服务端创建完ticket后，最好不要直接返回，而是先做一个数字签名，数字签名算法可以使用常用的RSA，如有必要再复杂化算法从而保证数据完整性
ticket加密完毕后，写到客户端的cookie中，后续客户端发起任何请求都要带着这个cookie，服务器会自动进行解密、验证，验证失败，则需要重新登录

对服务器的压力基本为0，服务器只是每次解密验证一下ticket。只需要保证不同的应用服务器中部署的代码中的加解密算法一样就行。

实现与流程上来说，与cookie的方式一样，区别是，token会放在请求头（这种方式用的比较多）或者请求参数中，而不是cookie中。服务端从请求头或者请求参数中获取到token进行验证。

这种方式对前端的友好度是最高的，前端只需要做两件事：

这两件事都是可以通过全局的组件或者模块封装来实现的，所以说，前端的工作量基本上是0。

ticket和token都存在一个问题，那就是刷新的问题。因为不管token的期限多久，总会有过期的时候，而如果过期的时候，用户恰好就在应用中操作，那么这时候用户会突然被踢出去，并要求重新登录，这肯定是不合理的。所以这时候就需要为用户自动更新token。

最简单的方式，就是前端捕获错误，而后静默自动登录获取新的token。这种方式的安全性不够，存在无限获取token的bug。于是OAuth2.0推出了refresh token的概念。以此来验证是否有获取新token的权限。

基于session的方式，它的安全重心就是SessionId，要保证足够随机才能避免被他人冒充。

基于cookie和token的方式，凭证都是一个在服务端签名加密过的字符串，安全中心就是签名和加密的算法，要保证密钥的安全性才能避免被篡改凭证，冒充他人。

Web应用最难解决的安全问题就是CSRF了。这种问题，从本质上来说，是代码的bug造成的，但是这种bug已经不是表层bug，有的bug甚至是和操作系统关联造成的。这种安全问题是很难遇到的，但是也是最难防护的。只能去了解常见的攻击方式并使用大佬给的应对方法。

至于更高级的，如HTTP劫持等，这些靠代码就已经防护不了了。就需要专业的安全工程师来对服务器就行安全防护。

关注