NUXT框架使用

NUXT（不是必须的，直接使用vue-admin-template也不是不可以）

项目构建

1. npm install -g npx
2. yarn install create-app nuxt-demo 创建项目
3. 先执行npm install，再执行 npm install vue-awesome-swiper@3.1.3 swiper --save 进行覆盖（后面不要再进行npm install操作，否则可能重新将swiper的版本覆盖）。后面执行npm install会覆盖掉的原因可能是因为lock.json文件的原因
4. 配置 nuxt.config.json

模仿vue-admin-template封装 axios

1. 安装 axios，npm install axios

2. 建立 utils 包，创建 request.js 文件，填充下面内容

   import axios from 'axios'
   
   const service = axios.create({
       baseURL: 'http://localhost:8001',
       timeout: 10000
   })
   
   export default service

3. 创建 api 包，在 api 文件夹下创建前端接口，例如 banner.js 文件

   import request from "@/utils/request";
   
   export default {
   
       /**
        * 查询所有的banner数据
        * @returns {Promise<AxiosResponse<any>>}
        */
       list() {
           return request({
               url: `/edu/crm/banner/user/list`,
               method: 'get',
           })
       }
   }

路由

固定路由

动态路由

传入课程的 id，不同课程有着不同的课程 id

NUXT 的动态路由是以下划线开头的 vue 文件，参数名为下划线后面的文件名，例如 _id.vue 表示接收参数为 id 的动态路由

轮播图业务

对首页（访问量大）进行缓存

Redis 中适合存放什么类型的数据？

• 经常进行查询，并且不经常修改的数据适合用 Redis 进行缓存。
• 不是特别重要的数据可以放到 Redis 中进行缓存

这些注解用于Service层还是Controller层呢？感觉应该存放在Service层中。

@Cacheable 和 @CachePut 是 Spring Framework 中用于缓存的注解。

@Cacheable 注解用于将方法的返回值缓存起来，以便在相同的参数传递给该方法时，可以直接返回缓存中的结果，而不需要执行实际的方法。(用于查询方法)

@CachePut 注解用于更新缓存中的数据，即使被注解的方法每次都会执行，也会将结果缓存起来。与 @Cacheable 不同的是，@CachePut 注解的方法始终会被执行，并将结果放入缓存中，以便后续使用。（用于新增方法）

@CacheEvict注解用于清空指定的缓存，一般用于更新方法或删除方法

需要注意的是，@Cacheable 和 @CachePut 注解的使用需要在 Spring Framework 中启用缓存支持，可以通过在配置类上添加 @EnableCaching 注解来启用缓存支持。

似乎添加上这些注解就不需要显式地使用redisTemplate来进行Redis的数据操作吗？

登录业务

单一服务器登录方式

使用session对象实现，在用户登录成功后，把用户数据放到session中。通过判断session中是否有数据来判断是否登录。

session.setAttribute("user", user);

session.getAttribute("user");

这种方式只适合单一服务器，不适合服务器是集群和分布式的情况，不能实现单点登录的需求，只适合学习使用。

微服务模块在不同的服务器中，如果使用session对象，那么在某一个微服务中登录并保存，那么在另一个微服务中还需要再次登录。实际需求是要实现单点登录，即在项目中的任何一个模块中登录，在其他模块都不需要再次登录

单点登录的应用场景：登录百度账号后，访问百度文库、百度贴吧、百度知道等服务时自动登录，不需要再次输入账号密码来进行登录验证。

SSO（Single Sign On单点登录）

单点登录的实现方式：

• 使用 session 的广播机制（session复制，复制造成浪费，现在被淘汰）
• 使用 cookie + redis 来实现
• 使用 token 来实现

随机值state由应用程序生成，传递给认证服务器，之后认证服务器返回token时会顺带返回state值，state值的作用是为了防止伪造攻击，在应用程序收到token时会验证state值，确认这真的是认证服务器发送过来的token

token由认证服务器生成

使用cookie和redis实现步骤：

1. 用户访问应用程序A。用户在浏览器中输入应用程序A的网址，然后浏览器将向应用程序A发送请求。
2. 应用程序A检查用户是否已登录。应用程序A检查浏览器中是否存在SSO cookie，如果存在，则检查Redis中是否有相应的会话数据。如果会话数据存在，则说明用户已经在其他应用程序登录过，并且可以直接访问应用程序A。
3. 应用程序A重定向到认证服务器。如果用户没有登录，则应用程序A将重定向用户到认证服务器，并将当前应用程序A的URL作为参数传递给认证服务器。此外，应用程序A还需要生成一个随机的state值，并将其保存在Redis中，以便后续验证。
4. 用户登录认证服务器。用户在认证服务器上输入其凭据（用户名和密码）以登录。
5. 认证服务器验证用户凭据并生成令牌。认证服务器验证用户凭据，并生成一个包含有关用户身份的令牌。
6. 认证服务器重定向到应用程序A。认证服务器将用户重定向回应用程序A，并将令牌作为参数传递给应用程序A。此外，还需要将步骤3中生成的state值一并传递给应用程序A。
7. 应用程序A验证state值和令牌。应用程序A检查传递回来的state值是否与之前保存在Redis中的相同。如果不同，则说明这个请求可能来自恶意的第三方，并且应用程序A应该拒绝这个请求。如果state值相同，则应用程序A从Redis中获取令牌，并验证令牌的有效性。如果令牌有效，则为用户创建一个会话，并设置SSO cookie以便在其他应用程序中进行验证。
8. 用户访问应用程序B。用户访问应用程序B时，应用程序B首先检查浏览器中是否存在SSO cookie。如果存在，则应用程序B将检查Redis中是否有相应的会话数据。如果会话数据存在，则说明用户已经在其他应用程序登录过，并且可以直接访问应用程序B。

需要注意的是，使用cookie和Redis来实现SSO时，需要确保Redis中保存的会话数据和cookie中保存的数据一致。此外，为了提高安全性，还需要定期清理Redis中的过期数据。

sequenceDiagram
    participant ClientApp
    participant AuthorizationServer
    participant UserAgent

    ClientApp->>UserAgent: 1. Redirect to AuthorizationServer(携带生成的随机state值)
    UserAgent->>AuthorizationServer: 2. Send authorization request
    AuthorizationServer->>UserAgent: 3. Ask for user credentials
    UserAgent->>AuthorizationServer: 4. Send user credentials
    AuthorizationServer->>ClientApp: 5. Redirect to client callback URL with authorization code
    ClientApp->>AuthorizationServer: 6. Request access token using authorization code
    AuthorizationServer->>ClientApp: 7. Return access token

sequenceDiagram
    participant User
    participant App1
    participant App2
    participant AuthServer
    participant Redis

    User->>+App1: Login request
    App1->>+AuthServer: Redirect to AuthServer for authentication
    AuthServer->>+User: Prompt for credentials
    User->>+AuthServer: Enter credentials
    AuthServer->>+Redis: Create SSO session and generate token
    Redis->>-AuthServer: Store SSO session and token
    AuthServer->>-App1: Redirect back to App1 with token
    App1->>+AuthServer: Request user info using token
    AuthServer->>+Redis: Validate token and retrieve user info
    Redis->>-AuthServer: Return user info
    AuthServer->>-App1: Return user info
    App1->>+App2: Forward user info to App2
    App2->>+AuthServer: Request user info using token
    AuthServer->>+Redis: Validate token and retrieve user info
    Redis->>-AuthServer: Return user info
    AuthServer->>-App2: Return user info

使用token实现步骤：

1. 用户访问应用程序。用户在浏览器中输入应用程序的网址，然后浏览器将向应用程序发送请求。
2. 应用程序重定向到认证服务器。当应用程序收到请求后，它将重定向用户到认证服务器。在重定向时，应用程序将向认证服务器传递一个特定的标识符，以便认证服务器可以识别应用程序。
3. 用户登录认证服务器。用户输入其凭据（用户名和密码）来登录认证服务器。
4. 认证服务器发放令牌。认证服务器通过验证用户凭据，然后发放一个令牌给用户。这个令牌包含有关用户身份的信息，例如用户名和权限等。
5. 用户被重定向回应用程序。认证服务器将用户重定向回应用程序，并将令牌一并发送给应用程序。
6. 应用程序验证令牌。应用程序收到令牌后，将与认证服务器通信以验证令牌的有效性。如果令牌有效，则应用程序会为用户创建一个会话，使用户可以在不需要再次登录的情况下访问应用程序。
7. 用户访问应用程序。现在，用户已经被授权访问应用程序，并且可以在不需要再次输入凭据的情况下访问应用程序。

JWT

给定一个生成 token 的规则。用来保存用户信息，至少应该保存用户id（唯一标识符），为了尽可能少的查询数据库，还可以包含一些基本的重要信息，例如用户身份（普通用户、vip、svip等）。

整合阿里云短信服务

微信扫码登录

OAuth2流程图

单点登录解决是同一个系统内部的各个微服务之间的问题，OAuth2是解决不同系统之间的互相访问，OAuth2并不会授予客户端全部的权限。

sequenceDiagram
    participant User
    participant Client
    participant Authorization_Server
    participant Resource_Server
    User->>Client: 1.发起请求（请求通过微信登录应用程序）
    Client->>Authorization_Server: 2.请求授权
    Authorization_Server->>User: 3.用户登录并授权
    User->>Authorization_Server: 4.同意授权
    Authorization_Server->>Client: 5.返回授权码/验证码（code）
    Client->>Authorization_Server: 6.请求访问令牌（code+app_id+app_secret）
    Authorization_Server->>Client: 7.返回访问令牌（access_token）
    Client->>Resource_Server: 8.请求资源
    Resource_Server-->>Client: 9.返回受保护资源

为什么要先获取授权码，再获取token令牌？

授权码是尽可能确认是用户本人在操作，例如用曾经登录过的手机扫码，而新手机无法直接登录。授权码可以理解成发送给手机的动态验证码，即使用户的账号密码泄露，也需要授权码才能获得访问令牌（真实的访问权限）