ES6 day-04 身份认证

BXY369

已于 2024-09-21 14:18:59 修改

阅读量775

点赞数 28

分类专栏： ES6 文章标签： es6 前端 ecmascript

于 2024-09-05 10:00:00 首次发布

本文链接：https://blog.csdn.net/BXY369/article/details/141748931

版权

ES6 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一. Web 开发模式

目前主流的 Web 开发模式有两种，分别是:

基于服务端渲染的传统 Web 开发模式
基于前后端分离的新型 Web 开发模式

1.1 服务端渲染的开发模式

特点：

所有的web资源由同一个服务器统一管理（前后端代码必须放到一起）
页面和页面中使用的数据，由服务器组装，最后将完整的HTML页面响应给客户端

优点：

前端耗时少。因为服务器端负责动态生成 HTML 内容，浏览器只需要直接渲染页面即可。尤其是移动端，更省电。
有利于SEO。因为服务器端响应的是完整的 HTML 页面内容，所以爬虫更容易爬取获得信息，更有利于 SEO。

缺点:

占用服务器端资源。即服务器端完成 HTML 页面内容的拼接，如果请求较多，会对服务器造成一定的访问压力。
不利于前后端分离，开发效率低。使用服务器端渲染，则无法进行分工合作，尤其对于前端复杂度高的项目，不利于项目高效开发。

1.2 前后端分离的开发模式

特点：

依赖于Ajax技术。
后端不提供完整的 HTML 页面内容，而是提供一些 API 接口
前端通过 Ajax 调用后端提供的 API 接口，拿到 json 数据之后再在前端进行 HTML 页面的拼接，最终展示在浏览器上。

简而言之，前后端分离的 Web 开发模式，就是后端只负责提供 API 接口，前端使用 Ajax 调用接口的开发模式。

优点：

开发体验好。前端专注于 UI 页面的开发，后端专注于api 的开发，且前端有更多的选择性。
用户体验好。Ajax 技术的广泛应用，极大的提高了用户的体验，可以轻松实现页面的局部刷新。
减轻了服务器端的渲染压力。因为页面最终是在每个用户的浏览器中生成的。

缺点：

不利于SEO。因为完整的 HTML 页面需要在客户端动态拼接完成，所以爬虫对无法爬取页面的有效信息。

(解决方案:利用 Vue、React 等前端框架的 SSR (server side render)技术能够很好的解决 SEO 问题!)

1.3 如何选择 Web 开发模式

比如企业级网站（公司的网站），主要功能是展示而没有复杂的交互，并且需要良好的 SEO，则这时我们就需要使用服务器端渲染;
而类似后台管理页面，交互性比较强，不需要 SEO 的考虑，那么就可以使用前后端分离的开发模式。
另外，具体使用何种开发模式并不是绝对的，为了同时兼顾了首页的渲染速度和前后端分离的开发效率，一些网站采用了首屏服务器端渲染，即对于用户最开始打开的那个页面采用的是服务器端渲染，而其他的页面采用前后端分离开发模式。
c端和B端

二. 身份认证机制

由于开发模式不同，身份认证也不同。

对于服务器渲染和前后端分离这两种开发模式来说，分别有不同的身份认证：

服务端渲染：即前后端不分离，推荐使用 session 认证机制，有利于 SEO，不存在跨域。
前后端分离：推荐使用 JWT 机制，在后台加载速度快。可以跨域

2.1 Cookie

实现身份认证

搭建基础的服务器
- 下载安装第三方模块 express 和 cookie-parser
- 创建app.js
- 加载所需模块
  - ```
  const express = require('express');
```
- ```
const cookieParser = require('cookie-parser');
```
中间件配置 cookie-parser
```
app.use(cookieParser())
```
登录接口中
- 如果登录成功，设置cookie。res.cookie('key', 'value', 配置项);

优缺点

优点
- 体积小
- 客户端存放，不占用服务器空间
- 浏览器会自动携带，不需要写额外的代码，比较方便
缺点
- 客户端保存，安全性较低。但可以存放加密的字符串来解决
- 只能存字符串，cookie的大小也是有限制的
- 可以实现跨域，但是难度大，难理解，代码难度高
- 不适合前后端分离式的开发

适用场景

传统的服务器渲染模式
存储安全性较低的数据，比如视频播放位置等

2.2 Session

实现身份认证

搭建基础的服务器
- 下载安装第三方模块 express 和 express-session
- 创建app.js
- 加载所需模块
  - ```
  const express = require('express');
```
- ```
const session = require('express-session');
```

中间件配置 session

app.use(session({
    secret: 'zml',
    name: 'glst',
    resave: false,
    saveUninitialized: true,
    cookie: {
        maxAge: 24 * 60 * 60 * 1000
    },
    rolling: true
}));

完成登录接口
- 如果登录成功，使用session记录用户信息。
```
req.session.username = 'zhangmeili';
```
接口中，根据session判断是否登录，从而完成身份认证。

优缺点

优点
- 服务端存放，安全性较高。
- 浏览器会自动携带cookie，不需要写额外的代码，比较方便。
- 适合服务器端渲染模式。
缺点
- 会占用服务器端空间。
- session实现离不开cookie，如果浏览器禁用cookie，session不好实现。
- 不适合前后端分离式的开发。

适用场景

传统的服务器渲染模式。
安全性要求较高的数据可以使用session存放，比如用户私密信息、验证码等。

2.3 JWT

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

jwt广义：jwt就是签发token和校验token的一种机制。
jwt狭义：jwt就是token。

流程：

用户使用用户名密码来请求服务器。（服务器--后端）
服务器进行验证用户信息。
服务器通过验证发给用户一个token。（后台给前端生成一个token，然后返回给前端）
客户端存储token，并在每次访问时加上这个token值。（客户端--前端）（每次访问后台接口的时候都需要加上token）
服务器验证token值并返回数据。
这个token必须在每次请求时传递给服务器，他应该保存在请求头里，另外服务端要支持CORS(跨来资源共享)的策略。

起源

说起JWT，我们应该来谈一谈基于token的认证和传统的session认证的区别。

JWT优点

因为json的通用性。所以JWT是可以跨语言的。

便于传输，JWT构成非常简单，字节占用很小，所以它是非常便于传输的。

他不需要在服务端保存会话信息，所以易于应用的扩展。

JWT的组成部分

1.Header(头）作用：记录令牌类型、签名算法等例如：{“alg":"HS256","type","JWT}

2.Payload(有效载荷）作用：携带一些用户信息例如{"userId":"1","username":"mingzi"}

3.Signature(签名）作用：是对前两部分的签名，防止Token被篡改、确保安全性例如计算出来的签名，一个字符串

实现身份认证

实现JWT方式的身份认证，我们需要下面两个第三方模块。

jsonwebtoken是用来生成token给客户端的

jwt.sign({存入token的信息}, '加密的key', {配置项})

jwt.verify(token, secretOrPrivateKey, function (err, decode)验证token

也可以使用express-jwt来验证token的。
- 可以解析token，从token中获取保存的信息，并赋值给req.user
- 可以控制哪些接口不需要权限，哪些接口需要权限
- 如果出错，会把错误信息next，也就是说，后面的错误处理中间件可以得到这个错误信息
- ```
app.use(expressJWT({secret: '加密的key'}).unless({path: /^\/api/}))
```