前端鉴权

front_Iris
231 阅读26分钟

为什么需要鉴权

由于HTTP 是无状态的。也就是说，HTTP 请求方和响应方间无法维护状态，都是一次性的，它不知道前后的请求都发生了什么。但有的场景下，我们需要维护状态。最典型的，一个用户登陆微博，发布、关注、评论，都应是在登录后的用户状态下的。

Cookie

cookie 也是前端存储的一种，但相比于 localStorage 等其他方式，cookie借助 HTTP 头、浏览器能力，就可以直接让http携带cookie发送请求,而不需要前端代码手动设置, cookie 可以做到前端无感知。

cookie的设置

  1. 客户端发送 HTTP 请求到服务器
  2. 当服务器收到 HTTP 请求时，在响应头里面添加一个 Set-Cookie 字段
  3. 浏览器收到响应后保存下 Cookie
  4. 之后对该服务器每一次请求中都通过 Cookie 字段将 Cookie 信息发送给服务器。

image.png

cookie的属性

1.name
表示cookie的名字，一个域名下绑定的cookie，name不能相同，相同的name的值会被覆盖掉 2.value
由于cookie规定是名称/值是不允许包含分号，逗号，空格的，所以为了不给用户到来麻烦，考虑服务器的兼容性，任何存储cookie的数据都应该被编码。
3.domain/path(cookie跨域配置)
Domain属性指定浏览器发出 HTTP 请求时，哪些域名要附带这个 Cookie。如果没有指定该属性，浏览器会默认将其设为当前 URL 的一级域名，比如 www.example.com 会设为 example.com，而且以后如果访问example.com的任何子域名，HTTP 请求也会带上这个 Cookie。如果服务器在Set-Cookie字段指定的域名，不属于当前域名，浏览器会拒绝这个 Cookie。

Path属性指定浏览器发出 HTTP 请求时，哪些路径要附带这个 Cookie。只要浏览器发现，Path属性是 HTTP 请求路径的开头一部分，就会在头信息里面带上这个 Cookie。比如，PATH属性是/，那么请求/docs路径也会包含该 Cookie。当然，前提是域名必须一致。
4.Expires
用于设置 Cookie 的过期时间, 比如Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

当没有设置Expires，表示是会话性 Cookie，当为会话性 Cookie 的时候，值保存在客户端内存中，并在用户关闭浏览器时失效。需要注意的是，有些浏览器提供了会话恢复功能，这种情况下即使关闭了浏览器，会话期 Cookie 也会被保留下来，就好像浏览器从来没有关闭一样。与会话性 Cookie 相对的是持久性 Cookie，持久性 Cookies 会保存在用户的硬盘中，直至过期或者清除 Cookie。这里值得注意的是，设定的日期和时间只与客户端相关，而不是服务端。 5.Max-Age
Max-Age 用于设置在 Cookie 失效之前需要经过的秒数。比如：

Set-Cookie: id=a3fWa; Max-Age=604800;

Max-Age 可以为正数、负数、甚至是 0。
如果 max-Age 属性为正数时，浏览器会将其持久化，即写到对应的 Cookie 文件中。
当 max-Age 属性为负数，则表示该 Cookie 只是一个会话性 Cookie。
当 max-Age 为 0 时，则会立即删除这个 Cookie。
假如 Expires 和 Max-Age 都存在，Max-Age 优先级更高。
6.Secure
标记为 Secure 的 Cookie 只应通过被HTTPS协议加密过的请求发送给服务端。使用 HTTPS 安全协议，可以保护 Cookie 在浏览器和 Web 服务器间的传输过程中不被窃取和篡改。
7.HTTPOnly
设置 HTTPOnly 属性可以防止客户端脚本通过 document.cookie 等方式访问 Cookie，有助于避免 XSS 攻击。
8.SameSite
SameSite 属性可以让 Cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（CSRF）。
SameSite 可以有下面三种属性值：
Strict 仅允许一方请求携带 Cookie，即浏览器将只发送相同站点请求的 Cookie，即当前网页 URL 与请求目标 URL 完全一致。
Lax 允许部分第三方请求携带 Cookie
None 无论是否跨站都会发送 Cookie\

Cookie 和 CSRF 的关系是什么

CSRF是什么？

CSRF，中文名叫跨站请求伪造，发生的场景就是，用户登陆了a网站，然后跳转到b网站，b网站直接发送一个a网站的请求，进行一些危险操作，就发生了CSRF攻击！ccsrf 不能获取到 cookie，但是可以利用浏览器的特性去使用。 接口的所有参数都是可以预测的（攻击网站清楚要伪造请求接口的请求参数）

那么为什么在b网站可以仿造a网站的请求？Cookie不是跨域的吗？什么条件下，什么场景下，会发生这样的事情？

这时候，我们要注意上面我对cookie的定义，在发送一个http请求的时候，携带的cookie是这个http请求域的地址的cookie。也就是我在b网站，发送a网站的一个请求，携带的是a网站域名下的cookie！很多同学的误解，就是觉得cookie是跨域的，b网站发送任何一个请求，我只能携带b网站域名下的cookie。

当然，我们在b网站下，读取cookie的时候，只能读取b网站域名下的cookie，这是cookie的跨域限制。所以要记住，不要把http请求携带的cookie，和当前域名的访问权限的cookie混淆在一起。

这是浏览器自带的特性, 浏览器使用 cookie 情况主要包括以下几点：\

除了跨域 XHR 请求情况下，浏览器在发起请求的时候会把符合要求的 cookie 自动带上。(域名，有效期，路径，secure 属性)
跨域 XHR 的请求的情况下，也可以携带 Cookie。
浏览器允许跨域提交表单
也就是说，浏览器中有页面或网站向某个域名发送请求时，其请求都会自动带上该域名下的所有 cookie。

还要理解一个点：CSRF攻击，仅仅是利用了http携带cookie的特性进行攻击的，但是攻击站点还是无法得到被攻击站点的cookie。这个和XSS不同，XSS是直接通过拿到Cookie等信息进行攻击的。

总结起来就是

在CSRF攻击中，就Cookie相关的特性：

1、http请求，会自动携带Cookie。

2、携带的cookie，还是http请求所在域名的cookie。

3、Cookie如何应对的 CSRF攻击？

明白了CSRF的本质，就能理解如何防御CSRF的攻击。

方案一：放弃Cookie、使用Token！

由于CSRF是通过Cookie伪造请求的方式，欺骗服务器，来达到自己的目的。那么我们采取的策略就是，不使用Cookie的方式来验证用户身份，我们使用Token！

Token的策略，一般就是登陆的时候，服务端在response中，返回一个token字段，然后以后所有的通信，前端就把这个token添加到http请求的头部。

这是当前，最常用的防御CSRF攻击的策略。

方案二：SameSite Cookies

它表示，只能当前域名的网站发出的http请求，携带这个Cookie。

当然，由于这是新的cookie属性，在兼容性上肯定会有问题。

方案三：服务端Referer验证

我们发送的http请求中，header中会带有Referer字段，这个字段代表的是当前域的域名，服务端可以通过这个字段来判断，是不是“真正”的用户请求。但是Referer字段可以伪造,所以并不是特别好的解决方案

Cookie 和 XSS 的关系是什么

1、XSS是什么

XSS是由于不安全的数据引起的，有可能是表单提交的数据，有可能是页面路径的参数问题。

CSRF是通过伪造http请求，来达到自己的攻击目的。但是XSS是通过盗取用户的敏感信息而达到攻击的目的。比如本地存储、用户密码、cookie等等。

比如这个不安全的数据，是一个script标签，那这个script就可以链接任意的js文件，浏览器本地就会执行这个js，那通过js我们能做的东西就太多了：

比如document.cookie，获取用户信息。

比如通过localStorage，获取本地存储的敏感信息（token）。

然后只要是这个页面展示的任何信息，我都可以获取。

2、Cookie 如何应对 XSS攻击

方案一：http-only

Cookie有一个http-only属性，表示只能被http请求携带。

假如你的网站遭受到XSS攻击，攻击者就无法通过document.cookie得到你的cookie信息。

方案二：正则校验

我们了解到，XSS是由于不安全的数据引起的，这些数据的来源，一个重要的渠道就是提交表单，注入到数据库。所以针对前端，我们需要把表单数据进行正则验证，通过验证之后，才能提交数据。

对于服务端，也应该对接受的数据，进行规则校验，不符合规则的数据不应该入库。从接口层面，保证数据安全。

方案三：数据转义

如果无法保证数据库的数据都是安全的，前端能做的事情就是，把所有需要展示到页面的数据，进行转义，比如遇到script标签，直接replace处理。或者遇到标签标识‘<’以及‘>’这类特殊字符，添加‘\’进行处理。

refresh token

token，作为权限守护者，最重要的就是「安全」。

业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？

一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。

另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。

  • access token 用来访问业务接口，由于有效期足够短，盗用风险小，也可以使请求方式更宽松灵活
  • refresh token 用来获取 access token，有效期可以长一些，通过独立服务和严格的请求方式增加安全性；由于不常验证，也可以如前面的 session 一样处理

如何跨域携带cookie

  • 前端请求时在request对象中配置"withCredentials": true；

  • 服务端在response的header中配置"Access-Control-Allow-Origin", "http://xxx:${port}";

  • 服务端在response的header中配置"Access-Control-Allow-Credentials", "true"

Session

  • session 是另一种记录服务器和客户端会话状态的机制
  • session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中
  • Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。 session 认证流程：
  • 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
  • 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
  • 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
  • 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

cookie和session的区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上.

简单的说，当你登录一个网站的时候，如果web服务器端使用的是session,那么所有的数据都保存在服务器上面，客户端每次请求服务器的时候会发送 当前会话的session_id，服务器根据当前session_id判断相应的用户数据标志，以确定用户是否登录，或具有某种权限。

由于数据是存储在服务器 上面，所以你不能伪造，但是如果你能够获取某个登录用户的session_id，用特殊的浏览器伪造该用户的请求也是能够成功的。

session_id是服务器和客户端链接时候随机分配的，一般来说是不会有重复，但如果有大量的并发请求，也不是没有重复的可能性。 Session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID 为标识符来存取服务器端的Session存储空间。而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一 SessionID提交到服务器端，来存取Session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用Cookie，那么Session也会失效。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。

3、设置cookie时间可以使cookie过期。但是使用session-destory（），我们将会销毁会话。

4、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。

5、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)

注意:

session很容易失效, 默认失效时间是30分钟,用户体验很差;

虽然cookie不安全,但是可以加密 ;

cookie也分为永久和暂时存在的;

浏览器 有禁止cookie功能 ,但一般用户都不会设置;

一定要设置失效时间,要不然浏览器关闭就消失了;

例如:

记住密码功能就是使用永久cookie写在客户端电脑，下次登录时，自动将cookie信息附加发送给服务端。

application是全局性信息，是所有用户共享的信息，如可以记录有多少用户现在登录过本网站，并把该信息展示个所有用户。

两者最大的区别在于生存周期，一个是IE启动到IE关闭.(浏览器页面一关 ,session就消失了)，一个是预先设置的生存周期，或永久的保存于本地的文件。(cookie)

Session信息是存放在server端，但session id是存放在client cookie的，当然php的session存放方法是多样化的，这样就算禁用cookie一样可以跟踪

Cookie是完全保持在客户端的如：IE firefox 当客户端禁止cookie时将不能再使用

Token

Acesss Token

  • 访问资源接口（API）时所需要的资源凭证

  • 简单 token 的组成： uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token 的前几位以哈希算法压缩成的一定长度的十六进制字符串）

  • 特点：

    • 服务端无状态化、可扩展性好
    • 支持移动端设备
    • 安全
    • 支持跨程序调用

  • token 的身份验证流程：

  1. 客户端使用用户名跟密码请求登录
  2. 服务端收到请求，去验证用户名与密码
  3. 验证成功后，服务端会签发一个 token 并把这个 token 发送给客户端
  4. 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
  5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 token
  6. 服务端收到请求，然后去验证客户端请求里面带着的 token ，如果验证成功，就向客户端返回请求的数据
  • 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
  • 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
  • token 完全由应用管理，所以它可以避开同源策略

Refresh Token

  • 另外一种 token——refresh token\

  • refresh token 是专用于刷新 access token 的 token。如果没有 refresh token，也可以刷新 access token，但每次刷新都要用户输入登录用户名与密码，会很麻烦。有了 refresh token，可以减少这个麻烦，客户端直接用 refresh token 去更新 access token，无需用户进行额外的操作。

  • Access Token 的有效期比较短，当 Acesss Token 由于过期而失效时，使用 Refresh Token 就可以获取到新的 Token，如果 Refresh Token 也失效了，用户就只能重新登录了。
  • Refresh Token 及过期时间是存储在服务器的数据库中，只有在申请新的 Acesss Token 时才会验证，不会对业务接口响应时间造成影响，也不需要向 Session 一样一直保持在内存中以应对大量的请求。

Token 和 Session 的区别

  • Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，不会存储会话信息。
  • 因为token相当于是一把钥匙,服务器通过解析这把钥匙来看是哪个用户的,所以相当于是用时间换空间(不需要像session一样吧sessionId存储在服务器中)
  • Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。

JWT

cookie/session 的问题：

从上面可以看出服务器种植 cookie 后每次请求都会带上 cookie，浪费带宽，而且 cookie 不支持跨域，不方便与其他的系统之间进行跨域访问，而服务器会用 session 来存储这些用户验证的信息，这样浪费了服务器的内存，当多个服务器想要共享 session 需要都拷贝过去。

JWT 的过程：

当用户发送请求，将用户信息带给服务器的时候，服务器不再像过去一样存储在 session 中，而是将浏览器发来的内容通过内部的密钥加上这些信息，使用 sha256 和 RSA 等加密算法生成一个 token 令牌和用户信息一起返回给浏览器，当涉及验证用户的所有请求只需要将这个 token 和用户信息发送给服务器，而服务器将用户信息和自己的密钥通过既定好的算法进行签名，然后将发来的签名和生成的签名比较，严格相等则说明用户信息没被篡改和伪造，验证通过。

JWT 的过程中，服务器不再需要额外的内存存储用户信息，和多个服务器之间只需要共享密钥就可以让多个服务器都有验证能力，同时也解决了 cookie 不能跨域的问题。

JWT 的结构

JWT 之所以能被作为一种声明传递的标准是因为它有自己的结构，并不是随便的发个 token 就可以的，JWT 用于生成 token 的结构有三个部分，使用 . 隔开。

1、Header

Header 头部中主要包含两部分，token 类型和加密算法，如 {typ: "jwt", alg: "HS256"}，HS256 就是指 sha256 算法，会将这个对象转成 base64。

2、Payload

Payload 负载就是存放有效信息的地方，有效信息被分为标准中注册的声明、公共的声明和私有的声明。

3、Signature

Signature 这一部分指将 Header 和 Payload 通过密钥 secret 和加盐算法进行加密后生成的签名，secret，密钥保存在服务端，不会发送给任何人，所以 JWT 的传输方式是很安全的。

最后将三部分使用 . 连接成字符串，就是要返回给浏览器的 token 浏览器一般会将这个 token 存储在 localStorge 以备其他需要验证用户的请求使用。

常见问题

使用 cookie 时需要考虑的问题

  • 因为存储在客户端，容易被客户端篡改，使用前需要验证合法性
  • 不要存储敏感数据，比如用户密码，账户余额
  • 使用 httpOnly 在一定程度上提高安全性
  • 尽量减少 cookie 的体积，能存储的数据量不能超过 4kb
  • 设置正确的 domain 和 path，减少数据传输
  • cookie 无法跨域
  • 一个浏览器针对一个网站最多存 20 个Cookie，浏览器一般只允许存放 300 个Cookie
  • 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 session 时需要考虑的问题

  • 将 session 存储在服务器里面，当用户同时在线量比较多时，这些 session 会占据较多的内存，需要在服务端定期的去清理过期的 session
  • 当网站采用集群部署的时候，会遇到多台 web 服务器之间如何做 session 共享的问题。因为 session 是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建 session 的服务器，那么该服务器就无法拿到之前已经放入到 session 中的登录凭证之类的信息了。
  • 当多个应用要共享 session 时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好 cookie 跨域的处理。
  • sessionId 是存储在 cookie 中的，假如浏览器禁止 cookie 或不支持 cookie 怎么办？ 一般会把 sessionId 跟在 url 参数后面即重写 url，所以 session 不一定非得需要靠 cookie 实现
  • 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 token 时需要考虑的问题

  • 如果你认为用数据库来存储 token 会导致查询时间太长，可以选择放在内存当中。比如 redis 很适合你对 token 查询的需求。
  • token 完全由应用管理，所以它可以避开同源策略
  • token 可以避免 CSRF 攻击(因为不需要 cookie 了)
  • 移动端对 cookie 的支持不是很好，而 session 需要基于 cookie 实现，所以移动端常用的是 token

使用 JWT 时需要考虑的问题

  • 因为 JWT 并不依赖 Cookie 的，所以你可以使用任何域名提供你的 API 服务而不需要担心跨域资源共享问题（CORS）
  • JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
  • JWT 不加密的情况下，不能将秘密数据写入 JWT。
  • JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
  • JWT 最大的优势是服务器不再需要存储 Session，使得服务器认证鉴权业务可以方便扩展。但这也是 JWT 最大的缺点：由于服务器不需要存储 Session 状态，因此使用过程中无法废弃某个 Token 或者更改 Token 的权限。也就是说一旦 JWT 签发了，到期之前就会始终有效，除非服务器部署额外的逻辑。
  • JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
  • JWT 适合一次性的命令认证，颁发一个有效期极短的 JWT，即使暴露了危险也很小，由于每次操作都会生成新的 JWT，因此也没必要保存 JWT，真正实现无状态。
  • 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。

使用加密算法时需要考虑的问题

  • 绝不要以明文存储密码
  • 永远使用 哈希算法 来处理密码，绝不要使用 Base64 或其他编码方式来存储密码，这和以明文存储密码是一样的，使用哈希，而不要使用编码。编码以及加密，都是双向的过程，而密码是保密的，应该只被它的所有者知道， 这个过程必须是单向的。哈希正是用于做这个的，从来没有解哈希这种说法， 但是编码就存在解码，加密就存在解密。
  • 绝不要使用弱哈希或已被破解的哈希算法，像 MD5 或 SHA1 ，只使用强密码哈希算法。
  • 绝不要以明文形式显示或发送密码，即使是对密码的所有者也应该这样。如果你需要 “忘记密码” 的功能，可以随机生成一个新的 一次性的（这点很重要）密码，然后把这个密码发送给用户。

分布式架构下 session 共享方案

1. session 复制

  • 任何一个服务器上的 session 发生改变（增删改），该节点会把这个 session 的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要 session ，以此来保证 session 同步

优点： 可容错，各个服务器间 session 能够实时响应。
缺点： 会对网络负荷造成一定压力，如果 session 量大的话可能会造成网络堵塞，拖慢服务器性能。

2. 粘性 session /IP 绑定策略

  • 采用 Ngnix 中的 ip_hash 机制，将某个 ip的所有请求都定向到同一台服务器上，即将用户与服务器绑定。 用户第一次请求时，负载均衡器将用户的请求转发到了 A 服务器上，如果负载均衡器设置了粘性 session 的话，那么用户以后的每次请求都会转发到 A 服务器上，相当于把用户和 A 服务器粘到了一块，这就是粘性 session 机制。

优点： 简单，不需要对 session 做任何处理。
缺点： 缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的 session 信息都将失效。
适用场景： 发生故障对客户产生的影响较小；服务器发生故障是低概率事件 。
实现方式： 以 Nginx 为例，在 upstream 模块配置 ip_hash 属性即可实现粘性 session。

3. session 共享（常用）

  • 使用分布式缓存方案比如 Memcached 、Redis 来缓存 session，但是要求 Memcached 或 Redis 必须是集群

  • 把 session 放到 Redis 中存储，虽然架构上变得复杂，并且需要多访问一次 Redis ，但是这种方案带来的好处也是很大的：

    • 实现了 session 共享；
    • 可以水平扩展（增加 Redis 服务器）；
    • 服务器重启 session 不丢失（不过也要注意 session 在 Redis 中的刷新/失效机制）；
    • 不仅可以跨服务器 session 共享，甚至可以跨平台（例如网页端和 APP 端）

4. session 持久化

  • 将 session 存储到数据库中，保证 session 的持久化

优点： 服务器出现问题，session 不会丢失
缺点： 如果网站的访问量很大，把 session 存储到数据库中，会对数据库造成很大压力，还需要增加额外的开销维护数据库。

只要关闭浏览器 ，session 真的就消失了？

不对。对 session 来说，除非程序通知服务器删除一个 session，否则服务器会一直保留，程序一般都是在用户做 log off 的时候发个指令去删除 session。
然而浏览器从来不会主动在关闭之前通知服务器它将要关闭，因此服务器根本不会有机会知道浏览器已经关闭，之所以会有这种错觉，是大部分 session 机制都使用会话 cookie 来保存 session id，而关闭浏览器后这个 session id 就消失了，再次连接服务器时也就无法找到原来的 session。如果服务器设置的 cookie 被保存在硬盘上，或者使用某种手段改写浏览器发出的 HTTP 请求头，把原来的 session id 发送给服务器，则再次打开浏览器仍然能够打开原来的 session。
恰恰是由于关闭浏览器不会导致 session 被删除，迫使服务器为 session 设置了一个失效时间，当距离客户端上一次使用 session 的时间超过这个失效时间时，服务器就认为客户端已经停止了活动，才会把 session 删除以节省存储空间。

参考文章juejin.cn/post/684490… juejin.cn/post/684490…

avatar
文章
阅读
粉丝