自定义注解实现接口鉴权（接口自动化鉴权）

本篇文章给大家谈谈自定义注解实现接口鉴权，以及接口自动化鉴权对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享自定义注解实现接口鉴权的知识，其中也会对接口自动化鉴权进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、Spring Security 接口认证鉴权入门实践指南
• 2、Spring Boot项目鉴权的4种方法
• 3、SpringBoot Starter自定义注解 - 接口加解密

Spring Security 接口认证鉴权入门实践指南

Web API 接口服务场景里自定义注解实现接口鉴权，用户的认证和鉴权是很常见的需求自定义注解实现接口鉴权，Spring Security 据说是这个领域里事实上的标准，实践下来整体设计上确实有不少可圈可点之处，也在一定程度上印证自定义注解实现接口鉴权了小伙们经常提到的 “太复杂了” 的说法也是很有道理的。

本文以一个简单的 SpringBoot Web 以应用为例，重点介绍以下内容：

创建 SpringBoot 示例，用于演示 Spring Security 在 SpringBoot 环境下的应用，简要介绍四部分内容：pom.xml、application.yml、IndexController 和 HelloController。

boot-example 是用于演示的 SpringBoot 项目子模块（Module）。

SpringBoot 应用名称为 example，实例端口为 9999 。

IndexController 实现一个接口：/。

HelloController 实现两个接口：/hello/world 和 /hello/name。

编译启动 SpringBoot 应用，通过浏览器请求接口，请求路径和响应结果：

SpringBoot 示例准备完成。

SpringBoot 集成 Spring Security 仅需要在 pom.xml 中添加相应的依赖： spring-boot-starter-security ，如下：

编译启动应用，相对于普通的 SpringBoot 应用，我们可以在命令行终端看到 特别 的两行日志：

表示 Spring Security 已在 SpringBoot 应用中生效。 默认 情况下，Spring Security 自动化 地帮助我们完成以下三件事件：

使用 Spring Security 默认为我们生成的用户名和密码进行登录（Sign in），成功之后会自动重定向至 / ：

之后我们就可以通过浏览器正常请求 /hello/world 和 /hello/name。

默认情况下，Spring Security 仅支持基于 FormLogin 方式的认证，只能使用固定的用户名和随机生成的密码，且不支持鉴权。如果想要使用更丰富的安全特性：

本文以 Java Configuration 的方式为例进行介绍，需要我们提供一个继承自 WebSecurityConfigurerAdapter 配置类，然后通过重写若干方法进而实现自定义配置。

SecurityConfig 使用 @Configuration 注解（配置类），继承自 WebSecurityConfigurerAdapter ，本文通过重写 configure 方法实现自定义配置。

需要注意： WebSecurityConfigurerAdapter 中有多个名称为 configure 重载方法，这里使用的是参数类型为 HttpSecurity 的方法。

注：Spring Security 默认自动化配置参考 Spring Boot Auto Configuration 。

用以指定哪些请求需要什么样的认证或授权，这里使用 anyRequest() 和 authenticated() 表示所有的请求均需要认证。

表示我们使用 HttpBasic 认证。

编译启动应用，会发现终端仍会输出密码：

因为，我们仅仅改变的是认证方式。

为方便演示，我们使用 CURL 直接请求接口：

会提示我们 Unauthorized ，即：没有认证。

我们按照 HttpBasic 要求添加请求头部参数 Authorization ，它的值：

即：

再次请求接口：

认证成功，接口正常响应。

使用默认用户名和随机密码的方式不够灵活，大部分场景都需要我们支持多个用户，且分别为自定义注解实现接口鉴权他们设置相应的密码，这就涉及到两个问题：

对于 读取 ，Spring Security 设计了 UserDetailsService 接口：

实现按照用户名（username）从某个存储介质中加载相对应的用户信息（UserDetails）。

用户名，客户端发送请求时写入的用于用户名。

用户信息，包括用户名、密码、权限等相关信息。

注意：用户信息不只用户名和用户密码。

对于 存储 ，Spring Security 设计了 UserDetailsManager 接口：

创建用户信息

修改用户信息

删除用户信息

修改当前用户的密码

检查用户是否存在

注意： UserDetailsManager 继承自 UserDetailsService 。

也就是说，我们可以通过提供一个已实现接口 UserDetailsManager * 的类，并重写其中的若干方法，基于某种存储介质，定义用户名、密码等信息的存储和读取逻辑自定义注解实现接口鉴权；然后将这个类的实例以 Bean 的形式注入 Spring Security，就可以实现用户名和密码的自定义。

实际上，Spring Security 仅关心如何 读取 ， 存储 可以由业务系统自行实现；相当于，只实现接口 UserDetailsService 即可。

Spring Security 已经为我们预置了两种常见的存储介质实现：

InMemoryUserDetailsManager和 JdbcUserDetailsManager 均实现接口 UserDetailsManager ，本质就是对于 UserDetails 的 CRUD 。我们先介绍 UserDetails ，然后再分别介绍基于内存和数据库的实现。

UserDetails是用户信息的抽象接口：

获取用户名。

获取密码。

获取权限，可以简单理解为角色名称（字符串），用于实现接口基于角色的授权访问，详情见后文。

获取用户是否可用，或用户/密码是否过期或锁定。

Spring Security 提供了一个 UserDetails 的实现类 User ，用于用户信息的实例表示。另外， User 提供 Builder 模式的对象构建方式。

设置用户名称。

设置密码，Spring Security 不建议使用明文字符串存储密码，密码格式：

其中，id 为加密算法标识，encodedPassword 为密码加密后的字符串。这里以加密算法 bcrypt 为例，详细内容可参考 Password Storage 。

设置角色，支持多个。

UserDetails实例创建完成之后，就可以使用 UserDetailsManager 的具体实现进行存储和读取。

InMemoryUserDetailsManager是 Spring Security 为我们提供的基于内存实现的 UserDetailsManager 。

使用 @Bean 将 InMemoryUserDetailsManager 实例注入 Spring Security。

创建 InMemoryUserDetailsManager 实例之后，并不是必须立即调用 createUser 添加用户信息，也可以在业务系统的其它地方获取已注入的 InMemoryUserDetailsManager 动态存储 UserDetails 实例。

编译启动应用，使用我们自己创建的用户名和密码（userA/123456）访问接口：

基于内存介质自定义的用户名和密码已生效，接口正常响应。

JdbcUserDetailsManager是 Spring Security 为我们提供的基于数据库实现的 UserDetailsManager ，相较于 InMemoryUserDetailsManager 使用略复杂，需要我们创建数据表，并准备好数据库连接需要的数据源（DataSource）, JdbcUserDetailsManager 实例的创建依赖于数据源。

JdbcUserDetailsManager可以与业务系统共用一个数据库数据源实例，本文不讨论数据源的相关配置。

以 MySQL 为例，创建数据表语句：

其他数据库语句可参考 User Schema 。

JdbcUserDetailsManager实例的创建与注入，除

之外，整体流程与 InMemoryUserDetailsManager 类似，不再赘述。

在业务系统中获取已注入的 JdbcUserDetailsManager 实例，可以动态存储 UserDetails 实例。

编译启动应用，使用我们自己创建的用户名和密码（userA/123456）访问接口：

基于数据库介质自定义的用户名和密码已生效，接口正常响应。

Spring Security 可以提供基于角色的权限控制：

假设，存在两个角色 USER（普通用户） 和 ADMIN（管理员），

角色 USER 可以访问接口 /hello/name，

角色 ADMIN 可以访问接口 /hello/world，

所有用户认证后可以访问接口 /。

我们需要按上述需求重新设置 HttpSecurity ：

设置角色 USER 可以访问接口 /hello/name。

设置角色 ADMIN 可以访问接口 /hello/world。

设置其他接口认证后即可访问。

mvcMatchers 支持使用通配符。

创建属于角色 USER 和 ADMIN 的用户：

用户名：userA，密码：123456，角色：USER

用户名：userB，密码：abcdef，角色：ADMIN

对于用户 userA ：

使用用户 userA 的用户名和密码访问接口 /：

认证通过，可正常访问。

使用用户 userA 的用户名和密码访问接口 /hello/name：

认证通过，鉴权通过，可正常访问。

使用用户 userA 的用户名和密码访问接口 /hello/world：

认证通过，用户 userA 不属于角色 ADMIN，禁止访问。

使用用户 userA 的用户名和密码访问接口 /：

认证通过，可正常访问。

对于用户 userB ：

使用用户 userB 的用户名和密码访问接口 /：

认证通过，可正常访问。

使用用户 userB 的用户名和密码访问接口 /hello/world：

认证通过，鉴权通过，可正常访问。

使用用户 userB 的用户名和密码访问接口 /hello/name：

认证通过，用户 userB 不属于角色 USER，禁止访问。

这里可能会有一点奇怪，一般情况下我们会认为 管理员 应该拥有 普通用户 的全部权限，即普通用户 可以访问接口 /hello/name，那么 管理员 应该也是可以访问接口 /hello/name 的。如何实现呢？

方式一，设置用户 userB 同时拥有角色 USER 和 ADMIN；

这种方式有点不够“优雅”。

方式二，设置角色 ADMIN 包含 USER；

Spring Security 有一个 Hierarchical Roles 的特性，可以支持角色之间的 包含 操作。

使用这个特性要特别注意两个地方：

前文使用的是 HttpSecurity.authorizeHttpRequests 方法，此处需要变更为 HttpSecurity.authorizeRequests 方法。

使用 RoleHierarchy 以 Bean 的方式定义角色之间的 层级关系 ；其中，“ROLE_” 是 Spring Security 要求的固定前缀。

编译启动应用，使用用户 userB 的用户名和密码访问接口 /hello/name：

认证通过，鉴权通过，可正常访问。

如果开启 Spring Security 的 debug 日志级别，访问接口时可以看到如下的日志输出：

可以看出，Spring Security 可以从角色 ADMIN 推导出用户实际拥有 USER 和 ADMIN 两个角色。

Hierarchical Roles 文档中的示例有明显错误：

接口 RoleHierarchy 中并不存在方法 setHierarchy 。前文所述 authorizeRequests 和 RoleHierarchy 结合使用的方法是结合网络搜索和自身实践得出的，仅供参考。

另外， authorizeHttpRequests 和 RoleHierarchy 结合是没有效果的， authorizeRequests 和 authorizeHttpRequests 两者之间的区别可以分别参考 Authorize HttpServletRequests with AuthorizationFilter 和 Authorize HttpServletRequest with FilterSecurityInterceptor 。

鉴权的前提需要认证通过；认证不通过的状态码为401，鉴权不通过的状态码为403，两者是不同的。

Spring Security 异常主要分为两种：认证失败异常和鉴权失败异常，发生异常时会分别使用相应的默认异常处理器进行处理，即：认证失败异常处理器和鉴权失败异常处理器。

使用的认证或鉴权实现机制不同，可能使用的默认异常处理器也不相同。

Spring Security 认证失败异常处理器：

如前文所述，认证失败时，Spring Security 使用默认的认证失败处理器实现返回：

如果想要自定义返回内容，则可以通过自定义认证失败处理器实现：

authenticationEntryPoint()会创建返回一个自定义的 AuthenticationEntryPoint 实例；其中，使用 HttpServletResponse.getWriter().print() 写入我们想要返回的内容：401。

httpBasic().authenticationEntryPoint(authenticationEntryPoint())使用我们自定义的 AuthenticationEntryPoint 替换 HttpBasic 默认的 BasicAuthenticationEntryPoint 。

编译启动应用，使用不正确的用户名和密码访问接口 /：

认证不通过，使用我们自定义的内容 401 返回。

Spring Security 鉴权失败异常处理器：

如前文所述，认证失败时，Spring Security 使用默认的认证失败处理器实现返回：

如果想要自定义返回内容，则可以通过自定义鉴权失败处理器实现：

自定义鉴权失败处理器与认证失败处理器过程类似，不再赘述。

编译启动应用，使用用户 userA 的用户名和密码访问接口 /hello/world：

鉴权不通过，使用我们自定义的内容 403 返回。

exceptionHandling()也是有一个 authenticationEntryPoint() 方法的；对于 HttpBasic 而言，使用 exceptionHandling().authenticationEntryPoint() 设置自定义认证失败处理器是不生效的，具体原因需要大家自行研究。

前文介绍两种认证方式： FormLogin 和 HttpBasic ，Spring Security 还提供其他若干种认证方式，详情可参考 Authentication Mechanisms 。

如果我们想实现自己的认证方式，也是比较简单的。Spring Security 本质就是 过滤器 ，我们可以实现自己的认证过滤器，然后加入到 Spring Security 中即可。

认证过滤器核心实现流程：

除去抛出异常的情况外， filterChain.doFilter(servletRequest, servletResponse); 是必须保证被执行的。

理解认证过滤器涉及的概念会比较多，详情参考 Servlet Authentication Architecture 。

认证过滤器创建完成之后，就可以加入到 Spring Security 中：

Spring Security 根据我们配置的不同，会为我们自动按照一定的次序组装一条 过滤器链 ，通过这条链上的若干过滤器完成认证鉴权的。我们需要把自定义的认证过滤器加到这个链的 合适位置 ，这是选取的位置是在 ExceptionTranslationFilter 的前面。

过滤器链的顺序可以参考 Security Filters 。

ExceptionTranslationFilter 的作用可以参考 Handling Security Exceptions 。

使用自定义认证过滤器时，自定义认证失败异常处理器和鉴权失败异常处理器的设置方法。

编译启动应用，我们会发现可以在不填入任何认证信息的情况下直接访问接口 / 和 /hello/name，因为模拟用户已认证且角色为 USER；访问接口 /hello/world 时会出现提示 403。

Spring Security 自身包含的内容很多，官方文档也不能很好的讲述清楚每个功能特性的使用方法，很多时候需要我们自己根据文档、示例、源码以及他人的分享，尽可能多的实践，逐步加深理解。

Spring Boot项目鉴权的4种方法

文章介绍了spring-boot中实现通用auth的四种方式自定义注解实现接口鉴权，包括 传统AOP、拦截器、参数解析器和过滤器自定义注解实现接口鉴权，并提供了对应的实例代码，最后简单总结了下他们的执行顺序。

前言

最近一直被无尽的业务需求淹没，没时间喘息，终于接到一个能让我突破代码舒适区的活儿，解决它的过程非常曲折，一度让我怀疑人生，不过收获也很大，代码方面不明显，但感觉自己抹掉了 java、Tomcat、Spring 一直挡在我眼前的一层纱。对它们的理解上了一个新的层次。好久没输出了，于是挑一个方面总结一下，希望在梳理过程中再了解一些其他的东西。

由于 Java 繁荣的生态，下面每一个模块都有大量的文章专门讲述。所以我选了另外一个角度，从实际问题出发，将这些分散的知识串联起来，各位可以作为一个综述来看。各个模块的极致详细介绍，大家可以去翻官方文档或看网络上的其他博客。需求很简单清晰，跟产品们提的妖艳需求一点也不一样自定义注解实现接口鉴权：在我们的 web 框架里添加一个 通用 的 appkey 白名单校验功能，希望它的扩展性更好一些。

这个 web 框架是部门前驱者基于 spring-boot 实现的，介于业务和 Spring 框架之间，做一些偏向于业务的通用性功能，如 日志输出、功能开关、通用参数解析等。平常是对业务透明的，最近一直忙于把需求做好，代码写好，甚至从没注意过它的存在。

传统AOP

对于这种需求，首先想到的当然是 Spring-boot 提供的 AOP 接口，只需要在 Controller 方法前添加切点，然后再对切点进行处理即可。

实现

其使用步骤如下自定义注解实现接口鉴权：

切面类伪代码如下：

在Controller方法上添加 @Whitelist 注解实现功能。

扩展

本例中使用了 注解 来声明切点，并且我实现了通过注解参数来声明要校验的白名单，如果之后还需要添加其他白名单的话，如通过 UID 来校验，则可以为此注解添加 uid() 等方法，实现自定义校验。此外，spring 的 AOP 还支持 execution（执行方法） 、bean（匹配特定名称的 Bean 对象的执行方法） 等切点声明方法和 @Around（在目标函数执行中执行） 、@After（方法执行后） 等通知方法。如此，功能已经实现了，但领导并不满意=_=，原因是项目中 AOP 用得太多了，都用滥了，建议我换一种方式。嗯，只好搞起。

Interceptor

Spring 的 拦截器(Interceptor) 实现这个功能也非常合适。顾名思义，拦截器用于在 Controller 内 Action 被执行前通过一些参数判断是否要执行此方法，要实现一个拦截器，可以实现 Spring 的 HandlerInterceptor 接口。

实现

实现步骤如下：

AppkeyInterceptor 类如下：

扩展

要启用 拦截器还要显式配置它启用，这里我们使用 WebMvcConfigurerAdapter 对它进行配置。需要注意，继承它的的 MvcConfiguration 需要在 ComponentScan 路径下。

还需要注意，拦截器执行成功后响应码为 200 ，但响应数据为空。

当使用拦截器实现功能后，领导终于祭出大招了：我们已经有一个 Auth 参数了，appkey 可以从 Auth 参数里取到，可以把在不在白名单作为 Auth 的一种方式，为什么不在 Auth 时校验？emmm… 吐血中。

如果您正在学习Spring Boot，那么推荐一个连载多年还在继续更新的免费教程：http://blog.didispace.com/spring-boot-learning-2x/

ArgumentResolver

参数解析器是 Spring 提供的用于解析自定义参数的工具，我们常用的 @RequestParam 注解就有它的影子，使用它，我们可以将参数在进入Controller Action之前就组合成我们想要的样子。Spring 会维护一个 ResolverList ， 在请求到达时，Spring 发现有自定义类型参数（非基本类型）， 会依次尝试这些 Resolver，直到有一个 Resolver 能解析需要的参数。要实现一个参数解析器，需要实现 HandlerMethodArgumentResolver 接口。

实现

实现的 AuthParamResolver 类如下：

扩展

当然，使用参数解析器也需要单独配置，我们同样在 WebMvcConfigurerAdapter 内配置：

这次实现完了，我还有些不放心，于是在网上查找是否还有其他方式可以实现此功能，发现常见的还有 Filter 。

Filter

Filter 并不是 Spring 提供的，它是在 Servlet 规范中定义的，是 Servlet 容器支持的。被 Filter 过滤的请求，不会派发到 Spring 容器中。它的实现也比较简单，实现 javax.servlet.Filter 接口即可。由于不在 Spring 容器中，Filter 获取不到 Spring 容器的资源，只能使用原生 Java 的 ServletRequest 和 ServletResponse 来获取请求参数。另外，在一个 Filter 中要显示调用 FilterChain 的 doFilter 方法，不然认为请求被拦截。实现类似：

扩展

Filter 也需要显示配置：

小结

四种实现方式都有其适合的场 景，那么它们之间的调用顺序如何呢？Filter 是 Servlet 实现的，自然是最先被调用，后续被调用的是 Interceptor 被拦截了自然不需要后续再进行处理，然后是 参数解析器，最后才是切面的切点。

SpringBoot Starter自定义注解 - 接口加解密

目标

本章我们将编写一个starter，目标如下：

1、对外提供 @OpenAPI 注解，使用此注解它会对接收的请求数据进行解密，对要返回的数据进行加密。

2、完成服务端使用示例

3、完成前端调用示例

加密规则

1、对业务数据进行AES加密，示意代码：encryptData=AES("业务数据", aesKey)

2、对AES的key进行公钥加密，示意代码：encryptKey=RSA(aesKey, 公钥)

3、签名sign=md5(encryptData+encryptKey)

加密后请求示例

Content-Type: application/x-www-form-urlencoded;charset=UTF-8

请求参数

服务端返回示例

pom.xml

定义注解

配置公私钥

具体代码逻辑

定义切面和自动装配

spring.factories

服务端修改

在业务项目中引入jar 包

配置公私钥

改动的地方很少，只需要在原接口增加@OpenAPI注解即可

前端修改

修改前代码

修改后要先对参数加密，然后对返回数据解密

安装两个加密库

封装RSA、AES和Base64加解密

关于自定义注解实现接口鉴权和接口自动化鉴权的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 自定义注解实现接口鉴权的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于接口自动化鉴权、自定义注解实现接口鉴权的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。