• article 文章表

• sys_permission 后台权限表

• sys_role 后台角色表

• sys_role_permission 角色-权限关联表

• sys_user 用户表

• sys_user_role 用户-角色关联表

sys_user_role

id user_id(用户id) role_id(角色id)

sys_role

id role_name(角色名) create_time(创建时间）update_time(更新时间) delete_status(删除状态)

article

id content(varchar 255 文章内容) create_time(timestamp 创建时间) update_time(timestamp 更新时间) delete_status(varchar 是否有效，1有效，2无效）

Spring框架中的@Configuration注解，表示这个类用于配置应用程序上下文。

实现了WebMvcConfigurer接口，这意味着该类将覆盖默认的Spring MVC配置，以便我们可以自定义Web应用程序的行为。

@Autowired注解用于自动装配loginHandler对象，这里的loginHandler是一个实现了Interceptor接口的拦截器实例。

在实现WebMvcConfigurer接口时，必须实现addInterceptors方法。此方法允许我们向注册表中添加自定义拦截器，以便它们能够拦截特定的请求并执行一些逻辑操作。

在addInterceptors方法内部，我们通过registry参数注册了一个loginHandler拦截器。这意味着每次发出HTTP请求时都会调用这个拦截器，并且该拦截器的逻辑将在请求被处理之前或之后执行。

@Configuration 和 @EnableCaching 是Spring框架中的两个注解。

@Configuration 用于标注一个类，表示这个类是一个配置类。Spring容器在启动时，会扫描带有该注解的类，并根据其中的@Bean等注解创建相应的Bean对象。

@EnableCaching 标注在配置类上，表示开启缓存支持。使用该注解时，需要在配置类中配置缓存管理器（如RedisCacheManager）以及缓存的一些参数。如果不配置缓存管理器，则默认使用ConcurrentMapCacheManager。

当我们在Spring应用中需要使用缓存时，只需要添加相应的注解即可，例如：@Cacheable、@CachePut 和 @CacheEvict 等。

总之，@Configuration 和 @EnableCaching 注解结合起来使用，可以方便地配置缓存管理器和缓存规则，并在需要缓存的方法上添加缓存注解，从而实现缓存功能。

一个配置类，用于配置默认的缓存管理器，并使用了Spring框架中的一些注解。

• @Primary 注解用于指定在多个同类型的 Bean 中优先选择哪个 Bean。这里我们将默认的缓存管理器标记为首选项。

• @Bean 注解用于告诉 Spring 容器，该方法返回的对象要注册为一个 Bean。在这里，我们将返回一个 CaffeineCacheManager 对象作为默认的缓存管理器，并且可以通过其 setCaffeine() 方法来设置一些缓存的属性。

• 在 setCaffeine() 方法中，我们使用了Caffeine作为缓存实现，并进行了如下设置：

  • expireAfterWrite() 方法设置最后一次写入后经过固定时间过期。

  • initialCapacity() 方法设置初始的缓存空间大小。

  • maximumSize() 方法设置缓存的最大条数。

这样我们就配置好了一个使用 Caffeine 作为缓存实现的默认缓存管理器，其中缓存数据会在 10 秒后过期。当需要使用缓存时，只需要调用该缓存管理器即可。

使用Spring框架中的@Bean注解定义了一个名为"tokenCacheManager"的Bean，它返回了一个由Caffeine库构建的缓存对象。具体注解说明如下：

@Bean("tokenCacheManager")：表示该方法返回一个Bean对象，并将其命名为"tokenCacheManager"。

public Cache<String, SessionUserInfo> caffeineCache()：该方法返回值为Caffeine缓存对象，并且该方法可以被其他组件引用，即可通过spring容器获取到这个对象。

return Caffeine.newBuilder()：创建一个新的缓存构造器。

.expireAfterAccess(30L, TimeUnit.MINUTES)：指定缓存条目在最后一次访问后，在固定时间（30分钟）之后过期。

.initialCapacity(100)：设置缓存初始容量为100。

.maximumSize(10000)：设置缓存最大容量为10000条数据。

.build()：调用build()方法构建Caffeine缓存对象，该缓存对象是Spring框架管理的一个单例Bean，在应用程序运行期间只会创建一次，其他组件可以通过依赖注入的方式来使用它。

MyBatis是一个开源的Java持久层框架，它可以帮助我们简化数据库操作，同时提供了一些高级特性，如自定义SQL、存储过程和高级映射等。MyBatis使得Java程序员能够更加方便地访问关系数据库，并且在操作上比JDBC更加灵活。

MyBatis的主要特点是通过简单的XML或注解来配置和映射原始类型、接口和POJO为数据库中的记录。这使得我们可以将数据库表映射到Java对象，从而进一步简化数据库操作过程。同时，MyBatis还支持动态SQL，允许我们根据运行时条件生成不同的SQL语句，从而实现更加复杂的查询和更新操作。

除此之外，MyBatis还具有良好的性能和可扩展性。它采用了缓存机制，可以缓存SQL语句和查询结果，从而避免了频繁地访问数据库。同时，MyBatis也支持插件机制，允许我们在不修改源码的情况下增强其功能。

总之，MyBatis是一个功能强大且易于使用的Java持久层框架，旨在帮助Java程序员更轻松地访问关系数据库。

使用了@Transactional注解来表示这个方法需要在一个事务中执行，如果出现异常则会回滚事务。具体注解的含义如下：

@Transactional(rollbackFor = Exception.class)

• @Transactional: 这是Spring框架提供的事务注解，用于表示该方法需要在一个事务中执行。

• rollbackFor = Exception.class：表示当方法抛出任何异常时，都会让事务回滚。

public JSONObject addArticle(JSONObject jsonObject) {

• public: 表示该方法可以被其他类调用。

• JSONObject: 返回值类型为JSONObject对象。

• addArticle: 方法名，用于添加文章到数据库。

• (JSONObject jsonObject): 接受一个JSONObject对象作为参数，该对象包含了文章的相关信息。

articleDao.addArticle(jsonObject);

• articleDao：数据访问对象，通过它来操作数据库。

• addArticle(jsonObject)：调用articleDao对象的addArticle方法添加文章到数据库，传入方法的参数为JSONObject对象。

return CommonUtil.successJson();

• return: 返回操作结果，这里返回了一个成功的JSONObject对象。

• CommonUtil：工具类，封装了一些常用的方法。

• successJson(): 静态方法，返回一个表示操作成功的JSONObject对象。

实现基于 Token 令牌的 Web 应用安全访问控制可以通过以下几个步骤实现：

1. 生成 Token：Token 可以由服务器生成，也可以由第三方认证服务提供商生成。在生成 Token 时，需要考虑 Token 的有效期、加密方式等因素。

2. 发送 Token：一旦生成了 Token，服务器需要将它发送给客户端。通常情况下，Token 在 HTTP 请求头中发送，例如 Authorization 头部中包含 Bearer Token。

3. 验证 Token：服务器在接收到请求时，需要从请求头中获取 Token，并对其进行验证。验证 Token 的过程通常涉及到解密、解析、校验有效期等步骤。

4. 授权访问：如果 Token 验证通过，服务器会对请求进行授权访问。通常情况下，服务器会将用户的权限信息存储在 Token 中，在进行授权访问时，需要先解析出用户的权限信息，然后再进行访问控制。

实现纯 Token 认证的 Web 应用时，可以通过关闭 Spring Security 自带的 Session、允许跨域请求，并增加一个 Token 拦截器来拦截所有请求并验证 Token 令牌是否有效。具体实现可参考以下步骤：

1. 关闭 Spring Security 自带的 Session：在 SecurityConfig 类中，可以通过 .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) 的方式关闭 Session。

2. 允许跨域请求：在 SecurityConfig 类中，可以通过 .cors() 的方式允许跨域请求。

3. 增加 Token 拦截器：创建一个 TokenInterceptor 类，实现 HandlerInterceptor 接口，并在 preHandle 方法中对 Token 进行验证。如果 Token 验证失败，可以返回错误信息或者直接拒绝请求。

4. 注册 Token 拦截器：在 WebMvcConfigurer 中注册 TokenInterceptor，使其生效。

如果想要实现 Session + Token 认证的 Web 应用，可以增加 Session、Token 拦截器来拦截所有请求，并根据请求是否带 Cookie 进行不同的认证授权。具体实现可参考以下步骤：

1. 创建 SessionInterceptor 类和 TokenInterceptor 类，并实现 HandlerInterceptor 接口。在 preHandle 方法中，分别对 Session 和 Token 进行验证。

2. 在 SecurityConfig 类中，关闭 Spring Security 自带的 Session，并增加一个 RememberMeConfigurer，将 Session ID 存储在 Cookie 中。

3. 注册 SessionInterceptor 和 TokenInterceptor，使其生效。

4. 在 TokenInterceptor 中，判断请求是否带有 Cookie。如果带有 Cookie，则使用 Session 进行认证授权，否则使用 Token 进行认证授权。

需要注意的是，虽然 Token 令牌不保存用户的认证信息，但是 Token 仍然需要进行加密处理以保证安全性。另外，在 Token 令牌的有效期到期之前，服务器需要定期更新 Token。

HTTP 协议本身是无状态的，也就是说服务器并不知道用户是否已经登录。为了解决这个问题，通常有以下两种方法：

1. 基于 Session 的身份验证

在基于 Session 的身份验证中，当用户第一次登录成功后，服务器会创建一个对应该用户的 Session，并将 Session ID 返回给客户端。客户端每次请求时需要带上该 Session ID，服务器通过验证 Session ID 来确定用户是否已经登录。

具体实现方式是：用户第一次登录成功后，服务器会生成一个唯一的 Session ID，并将该 ID 存储在某个地方（例如内存、数据库等）和客户端的 Cookie 中。当客户端再次请求时，会带上存储在 Cookie 中的 Session ID，服务器通过验证该 Session ID 来确定用户是否已经登录。如果 Session ID 有效，则认为用户已经登录；否则，认为用户未登录。

优点：相对简单易用，适合小型项目。

缺点：需要在服务器端保存 Session ID，占用一定的内存资源；同时，如果用户量较大，会导致服务器的性能瓶颈。

1. 基于 Token 的身份验证

在基于 Token 的身份验证中，当用户第一次登录成功后，服务器会生成一个 Token，并将该 Token 返回给客户端，客户端每次请求时需要带上该 Token，服务器通过验证 Token 来确定用户是否已经登录。

具体实现方式是：用户第一次登录成功后，服务器会生成一个唯一的 Token，并将该 Token 存储在某个地方（例如 Redis、数据库等）和客户端的 Cookie 或者请求头中。当客户端再次请求时，会带上存储在 Cookie 或者请求头中的 Token，服务器通过验证该 Token 来确定用户是否已经登录。如果 Token 有效，则认为用户已经登录；否则，认为用户未登录。

优点：相对于 Session，不需要在服务器端保存状态信息，极大降低了服务器的压力，适合分布式系统。

缺点：实现相对复杂，需要考虑 Token 的安全性和有效期等问题。

总之，选择使用哪种身份验证方式取决于具体项目的需求和场景。如果是小型项目，可以选择基于 Session 的身份验证方式；如果是大型项目或者分布式系统，可以选择基于 Token 的身份验证方式。

基于 Session 的认证方法是一种常用的用户身份验证方式，其主要流程如下：

1. 用户登录：用户在客户端输入用户名和密码进行登录。

2. 服务端生成 Session：服务器在接收到用户登录请求后，会为该用户生成一个 Session，并将 Session ID 返回给客户端。通常情况下，Session ID 会被存储在 Cookie 中。

3. 客户端发送请求：客户端每次向服务器发送请求时，都会带上存储在 Cookie 中的 Session ID。

4. 服务端验证 Session：服务器在接收到请求后，会根据 Session ID 去查找相应的 Session。如果能够找到对应的 Session，就说明用户已经通过了身份验证，可以继续执行后续操作；否则，就需要提示用户重新登录或者返回错误信息。

5. Session 管理：在用户退出登录或者一段时间不活跃之后，服务器需要及时销毁对应的 Session，释放资源。

需要注意的是，在分布式系统中，基于 Session 的认证方法需要考虑跨服务的问题。通常情况下，可以将 Session 存储在共享缓存（例如 Redis）中，以实现多个服务之间的 Session 共享。同时，为了保证安全性，还需要对 Session 进行加密处理，防止被恶意攻击者盗取或者篡改。

另外，基于 Session 的认证方法还有一些可拓展的方式，例如使用 JWT（JSON Web Token）替代 Session、使用 Spring Security 等第三方库来简化身份验证流程等。不同的拓展方式有着不同的适用场景和优缺点，需要根据具体项目需求进行选择。

基于 Token 的认证方法是一种不依赖于服务端 Session 的身份验证方式，其主要流程如下：

1. 用户登录：用户在客户端输入用户名和密码进行登录。

2. 生成 Token：服务器在接收到用户登录请求后，会根据一定的加密算法和密钥对用户信息进行加密处理，生成一个 Token，并将 Token 返回给客户端。

3. 客户端保存 Token：客户端在接收到服务器返回的 Token 后，会将其保存起来，通常情况下，Token 会被存储在客户端的 localStorage 或者 sessionStorage 中，并在每次向服务器发送请求时带上该 Token。

4. 服务端验证 Token：服务器在接收到请求后，会根据预先设定的密钥对 Token 进行解密，并校验 Token 的有效性。如果 Token 有效，则说明用户已经通过了身份验证，可以继续执行后续操作；否则，就需要提示用户重新登录或者返回错误信息。

5. Token 管理：在用户退出登录或者一段时间不活跃之后，服务器需要及时销毁对应的 Token，以保护用户的安全。

需要注意的是，在实现基于 Token 的认证方法时，需要考虑 Token 的安全性和有效期问题。为了保证安全性，通常会使用一些加密算法（例如 HMAC、RSA）对 Token 进行加密处理，从而防止 Token 被恶意攻击者盗取或者篡改。同时，为了防止 Token 被长时间滥用，还需要设置 Token 的有效期，并定期更新 Token。

另外，基于 Token 的认证方法还有一些可拓展的方式，例如使用 JWT（JSON Web Token）、OAuth 2.0 等开放标准协议来实现认证授权等。不同的拓展方式有着不同的适用场景和优缺点，需要根据具体项目需求进行选择。

验证码生成流程：前端发起验证码请求，后端程序生成验证码，将当前验证码信息保存到session并设置过期时间，返回前端base64编程等格式数据，前端处理验证码显示

加群联系作者vx：xiaoda0423

仓库地址：https://github.com/webVueBlog/JavaGuideInterview