个人备案网站类型,延吉市住房城乡建设局网站,wordpress横向导航,怎样到国外做合法网站法网站目录 前言
1.⽤户登录权限效验
1.1、最初⽤户登录效验
1.2、Spring AOP ⽤户统⼀登录验证的问题
1.3、Spring 拦截器
了解 创建一个 Spring 拦截器 的流程
1、 创建自定义拦截器#xff0c;实现 HandlerInterceptor 接⼝的preHandle#xff08;执⾏具体⽅法之前的预处理…目录 前言
1.⽤户登录权限效验
1.1、最初⽤户登录效验
1.2、Spring AOP ⽤户统⼀登录验证的问题
1.3、Spring 拦截器
了解 创建一个 Spring 拦截器 的流程
1、 创建自定义拦截器实现 HandlerInterceptor 接⼝的preHandle执⾏具体⽅法之前的预处理⽅法。
2、将⾃定义拦截器加⼊到框架的配置中并且设置拦截规则。
实践实现一个自定义的拦截器使其在项目中生效。
预备工作创建一个 Spring AOP 的项目。 1、 创建⾃定义拦截器实现 HandlerInterceptor 接⼝的preHandle执⾏具体⽅法之前的预处理⽅法。
2、将⾃定义拦截器加⼊到框架的配置中并且设置拦截规则。编辑
3、验收成果
拦截器实现原理
实现原理源码分析
拦截器小结
扩展统⼀访问前缀添加
2.统⼀异常处理
3.统⼀数据返回格式
为什么需要统⼀数据返回格式
统⼀数据返回格式的实现
总结
最后补充一点ControllerAdvice 源码分析 - 了解 前言
接下来是 Spring Boot 统⼀功能处理模块了也是 AOP 的实战环节要实现的⽬标有以下 3 个 1、统⼀⽤户登录权限验证 2、统⼀数据格式返回 3、统⼀异常处理。 接下我们⼀个⼀个来看。
1.⽤户登录权限效验 ⽤户登录权限的发展从之前每个⽅法中⾃⼰验证⽤户登录权限到现在统⼀的⽤户登录验证处理它是⼀个逐渐完善和逐渐优化的过程。 1、最初的用户登录效验在每个方法里面获取 session 和 session 中的 用户信息如果用户信息存在那么就登录成功了否则就登录失败了。 2、第二版用户登录效验提供了统一的方法在每个需要验证的方法中调用统一的用户登录身份效验方法来判断。 3、第三版用户登录效验 使用 Spring AOP 来使用统一的用户登录效验。 就是说不再需要我们敲代码去调用统一方法了Spring AOP 会帮我们自动调用。 1.1、最初⽤户登录效验
RestController
RequestMapping(/user)
public class UserController {//某⽅法 1RequestMapping(/m1)public Object method(HttpServletRequest request) {
// 有 session 就获取没有不会创建HttpSession session request.getSession(false);if (session ! null session.getAttribute(userinfo) ! null){
// 说明已经登录业务处理return true;} else {
// 未登录return false;}}//某⽅法 2 RequestMapping(/m2)public Object method2(HttpServletRequest request) {
// 有 session 就获取没有不会创建HttpSession session request.getSession(false);if (session ! null session.getAttribute(userinfo) ! null){
// 说明已经登录业务处理return true;} else {
// 未登录return false;}}
// 其他⽅法...
}从上述代码可以看出每个⽅法中都有相同的⽤户登录验证权限它的缺点是 1、 每个⽅法中都要单独写⽤户登录验证的⽅法即使封装成公共⽅法也⼀样要传参调⽤和在⽅法中进⾏判断。 2、 添加控制器越多调⽤⽤户登录验证的⽅法也越多这样就增加了后期的修改成本和维护成本。 3、 这些⽤户登录验证的⽅法和接下来要实现的业务几乎没有任何关联但每个⽅法中都要写⼀遍。所以提供⼀个公共的 AOP ⽅法来进⾏统⼀的⽤户登录权限验证迫在眉睫。 1.2、Spring AOP ⽤户统⼀登录验证的问题
说到统⼀的⽤户登录验证我们想到的第⼀个实现⽅案是 Spring AOP 前置通知或环绕通知来实现实现模板代码如下
Aspect
Component
public class UserAspect {// 定义切点⽅法 controller 包下、⼦孙包下所有类的所有⽅法Pointcut(execution(* com.example.demo.controller..*.*(..)))public void pointcut(){ }// 前置⽅法Before(pointcut())public void doBefore(){}// 环绕⽅法Around(pointcut())public Object doAround(ProceedingJoinPoint joinPoint){Object obj null;System.out.println(Around ⽅法开始执⾏);try {// 执⾏拦截⽅法obj joinPoint.proceed();} catch (Throwable throwable) {throwable.printStackTrace();}System.out.println(Around ⽅法结束执⾏);return obj;}
}如果要在以上 Spring AOP 的切⾯中实现⽤户登录权限效验的功能有以下两个问题 1、没办法获取到 HttpSession 对象。 2、我们要对⼀部分⽅法进⾏拦截⽽另⼀部分⽅法不拦截 如用户的注册⽅法和登录⽅法是不拦截的这样的话切点方法的拦截规则很难定义甚⾄没办法定义。 那这样如何解决呢 接下来我们就使用 Spring 提供的方案来解决 原始 AOP 所带来的问题。 这个解决方案也就是 第四版用户登录效验也是下面要讲的内容Spring 拦截器。 1.3、Spring 拦截器
对于以上问题 Spring 中提供了具体的实现拦截器HandlerInterceptor拦截器的实现分为以下两个步骤
1、 创建⾃定义拦截器实现 HandlerInterceptor 接⼝的 preHandle执⾏具体⽅法之前的预处理⽅法。 2、 将⾃定义拦截器加⼊ WebMvcConfigurer 的 addInterceptors ⽅法中。 有的人可能会有疑问Spring 拦截器 和 AOP 有什么关系呢? Spring 拦截器是基于 AOP 实现的。 因为 原生 AOP 没有办法获取 httpSession 和 Request 对象。而且拦截规则也非常难以定义。 所以官方就做了一个拦截器。 然后把我们之前最基础的 原生 AOP 做了一个封装 得到了一个新东西 “ Spring拦截器 ”。 我们也可以将 Spring 拦截器 称为是 Spring AOP 的一种实现。 Spring 拦截器中封装了很多对象对象里面就提供了专门的方法 来解决 原生 AOP 所带来的两个问题。 了解 创建一个 Spring 拦截器 的流程
1、 创建自定义拦截器实现 HandlerInterceptor 接⼝的preHandle执⾏具体⽅法之前的预处理⽅法。
HandlerInterceptor 的 中文意思 就是 拦截器。 重写 的 preHeadle 方法返回值的类型是 布尔类型。 返回是 true则表示通过了 拦截器的验证可以继续 执行调用 目标方法了。 反之验证没有通过直接返回一个错误信息。 总的来说拦截器 运行的模式 和 Spring AOP 是一样的。 起着一个 代理的作用。 现在是 前端先访问 拦截器执行里面的 preHandle 方法如果方法返回一个 true则继续执行后面的层序。 反之如果返回的是 false直接返回一个 错误信息后面的代码就不用执行了。 下面我们来看个具体的代码 public class LoginInterceptor implements HandlerInterceptor {Overridepublic boolean preHandle(HttpServletRequest request,HttpServletResponse response, Object handler) throws Exception {HttpSession session request.getSession(false);if (session ! null session.getAttribute(userinfo) ! null){return true;}response.setStatus(401);return false;}
}我们可以发现 preHandle方法中提供了 HttpServletRequest 和HttpServletResponse 的 对象 有了请求对象我们就可以获取到 Session 对象从而获取到里面的用户信息。 也就意味着我们可以进行用户登录状态的检测了 写法 和 Servlet 是 一样的这个你看上面的代码就知道了。 而且我们可以通过响应对象直接向前端返回一个 JSON 格式或者 HTML的数据。 甚至我还可以实现一些业务。 假设 用户处于未登录 状态我们可以通过 HttpServletResponse 发送重定向。 让用户直接跳转到 登录界面让他先去登录。 需要注意的是 虽然我们实现了拦截器但是 preHandle 方法 是一个普通方法。 没有程序去调用它。 因为我们没有给它加上任何注解。 没有加注解意味着 框架的 启动 和 这个没有任何关系。 另外这个自定义拦截器的方法只是具有拦截器的业务逻辑但是没有拦截的规则 所以才会有第二步将⾃定义拦截器加⼊到系统配置。 或者说配置到当前项目中。并且设置拦截的规则 2、将⾃定义拦截器加⼊到框架的配置中并且设置拦截规则。 Configuration
public class AppConfig implements WebMvcConfigurer {// 添加拦截器Overridepublic void addInterceptors(InterceptorRegistry registry) {registry.addInterceptor(new LoginInterceptor()).addPathPatterns(/**) // 拦截所有接⼝.excludePathPatterns(/art/param11); // 排除接⼝}
}大家需要注意一点
不管是 Spring还是 Spring Boot。它们默认的配置文件都是叫做 Spring MVC Configurer 的一个文件。
我们要设置当前的一些配置信息的时候我们是一定要去实现WebMvcConfigurer 接口的。 然后去重写里面的 addInterceptors添加多个拦截器方法。 只有这样系统才会认为 当前设置的东西 是给 当前项目去设置的配置文件。
所以说光加上 Configuration 注解是不行还必须实现 WebMvcConfigurer 接口重写里面的方法当前这个类才是一个配置文件。 这是一种固定写法注解 和 实现接口都不能少。 所有的当前项目的配置文件都是 来自于实现 WebMvcConfigurer 接口 。 所以这个接口是一定要实现的。
实现它之后 在当前类上 加上Configuration 注解是为了让 当前这个类 作为 系统的一个配置类。 此时类里面设置的东西在这里指的是拦截器才能生效。
而 addInterceptors - 添加多个拦截器方法表示 拦截器可以添加支持多个自定义拦截器。 即一个项目中可以设置多个拦截器。 比如 1、一个拦截器 去做登录的效验 2、一个拦截器 去验证 前端数据 的正确性 合法性。 等等。。。 并且不同的拦截器可以配置 不同的路由规则。 这个先暂且方法后面会细讲 ⾃定义拦截器加⼊到框架的配置中并且设置拦截规则。实现步骤1、在类上添加 Configuration 注解使其成系统的配置类2、当前类实现 WebMvcConfigurer 接口3、重写 WebMvcConfigurer 接口中的 addInterceptors 方法。上面讲述了 实现 Spring 拦截器的流程。 下面我们可以开始实践了 实践实现一个自定义的拦截器使其在项目中生效。
预备工作创建一个 Spring AOP 的项目。
这个 Spring 拦截器Spring Boot 项目 本身就支持 所以就不用引入 AOP 框架的支持了。 1、 创建⾃定义拦截器实现 HandlerInterceptor 接⼝的preHandle执⾏具体⽅法之前的预处理⽅法。
先在根目录下 创建一个 config 子包毕竟拦截类使用的是 configuration 注解。属于它的一部分。 并且在里面创建一个拦截类拦截器LoginIntercept。
因为我们要做的是 登录验证嘛就取名 Login后面的 Intercept 是拦截器的意思。 接下来开始实现 拦截器。 此时我们就实现了一个最简单的 验证用户登录状态的 拦截器自定义。
2、将⾃定义拦截器加⼊到框架的配置中并且设置拦截规则。 你们说难吗 其实也不难就是制定拦截规则需要过细一点。 不要把不该拦截的url忘记写就行了。
3、验收成果
我们先来给它加一个页面资源。 页面有了下面我们来创建 controller 层的代码。【负责与前端交互的代码】
下面我们先在没有登录的情况访问那些被拦截的资源 还有一个 index 的 静态页面对吧我们也来试一下效果与 访问 index 方法是一样的效果。因为没有登录嘛再来访问那些 没有被拦截的资源。 再来访问那些 没有被拦截的资源。
我们在这里在拓展一下业务。 在未登录的情况下访问其他访问方法或者页面让其跳转到登录页面。 此时我们先去访问 login方法登录成功后再去访问 index 方法 效果就出来了非常的nice
拦截器实现原理 拦截器实现原理 然⽽有了拦截器之后会在调⽤ Controller 之前进⾏相应的业务处理执⾏的流程如下图所示 实现原理源码分析 所有的 Controller 执⾏都会通过⼀个调度器 DispatcherServlet 来实现这⼀点可以从 Spring Boot 控制台的打印信息看出如下图所示 那么问题来了为什么执行每一条请求的时候都会先去调用 DispatcherServlet 呢 先从字面意思来看 Dispatcher 的 中文意思是 调度器分发器。 也就是说所有的请求进来之后会先进入调度器由调度器进行分发。 举个例子 上学的时候每个老师都有一个课代表对不对 没次发作业本的时候不是直接由老师发到你手里的。 一般都是把作业全部交给课代表有课代表分法作业。 原因很简单 1、方便不用自己动手 2、老师不止带一个班所以对每个学生坐的位置不是了解。分发的效率低。 3、课代表也班级中一员。对每个人的位置很熟悉发作业效率要高一些。放在程序里也是一样的理由。 DispatcherServlet 就是 “课代表”对方每个映射方法都“轻车熟路”执行的效率极高。 ⽽所有⽅法都会执⾏ DispatcherServlet 中的 doDispatch 调度⽅法. 另外为什么Spring 封装的拦截器的 preHandle 方法中会封装了 HttpServletRequest 和HttpServletResponse 呢 也是因为 它执行目标方法之前回调用 DispatcherServlet 中 doDispatch 方法。 进行预处理的时候就会使用 这两参数 顺水推舟你要用我就给你传嘛。 拦截器小结 通过上⾯的源码分析我们可以看出Spring 中的拦截器也是通过动态代理和环绕通知的思想实现的⼤体的调⽤流程如下 这个时候原本 Spring AOP 的 切面类代理对象 换成了 DispatcherServlet 。 一个是我们自定义的一个 Spring 框架 自带的。 不过执行原理并没有变。 用户 想要与 目标对象 直接交互必须要通过 代理对象拦截器的验证。 验证通过才有资格访问目标对象 扩展统⼀访问前缀添加 所有请求地址添加 api 前缀 index 方法也是一样的 2.统⼀异常处理
对于 统一异常处理提出一个问题如果不统一处理异常会是什么效果 本来按道理来说是返回一个 JSON 格式的信息因为前后端都是通过JSON 来交流的。但是我 “ 不小心 ” 写出了一个 bug 解决的办法我们就需要对所有的异常做一个拦截。 有的人可能会说我可以给那些可能会出现异常的带啊使用 tryCatch 包裹。但是这些导致代码太长了阅读性还低 尤其是涉及到 事务如果你乱使用 tryCatch 会导致 事务 无法正常进行回滚。 从而出现 预料之外的错误。 为了解决这个问题我们在 Spring 中 使用的是 统一异常处理的方式来解决。 对所有的异常进行一个拦截。 拦截之后你 “ 想干嘛就干嘛 ”. 你想返回一个什么形式的代码给前端都可以。 统⼀异常处理使⽤的是 ControllerAdvice ExceptionHandler 来实现的. ControllerAdvice 表示:控制器通知类 ExceptionHandler 是异常处理器 两个结合表示: 当出现异常的时候执⾏某个通知也就是执⾏某个⽅法事件。 统⼀异常处理 的实现有两步 1、给当前统一处理的类上加上 ControllerAdvice 注解。 ControllerAdvice 注解你可以认为该类是 controller 的通知类或者 说这是对 Controller 里面方法的增强。 Controller的通知指的是 controller 里面出现什么问题之后我能走到这个通知的方法里执行相应的处理。 2、给方法上添加一个 ExceptionHandler 注解。 ExceptionHandler Exception异常 Handler 处理器 / 管理器 然后呢 ExceptionHandler 注解后面 需要带有参数表明处理异常的类型。 进一步认证一下我们使用 fiddler 抓个包。 现在放心了吧前端在拿到这个响应知道它是一个算术异常他就可以对其进行“包装”然后返回给用户比如非法操作此接口异常稍后再试、 也就是说后端一般返回的错误信息是给 前端程序员去使用的。 前端程序员会根据错误信息比如对错误码进行“包装”让用户看的懂。 比如 404 未找到对应的资源。 我们来访问一个不存在的资源以b站为例。因为它的页面做的确实很好 这里需要注意的是 没有定义拦截的异常。 是不会被拦截的。 来看下面的例子 此时我们丢出一个想法上面写的异常拦截方法是具有很强的针对性的一个方法针只能针对一种错误类型。那么存不存在一种 “ 灵活 ” 写法。简单来说对于 异常类型我们不写死。我们一个方法就能拦截多种类型的异常甚至所有的异常都可以拦截 当然自定义的异常类型另说。不过差别也不大。 我们来一个暴力解法直接 异常的源头 Exception 作为 ExceptionHandler 参数对象。 这样我们不就可以拦截所有的异常类型了嘛 3.统⼀数据返回格式
为什么需要统⼀数据返回格式
统⼀数据返回格式的优点有很多⽐如以下⼏个 1、 ⽅便前端程序员更好的接收和解析后端数据接⼝返回的数据。 2、 降低前端程序员和后端程序员的沟通成本按照某个格式实现就⾏了因为所有接⼝都是这样返回的。 3、 有利于项⽬统⼀数据的维护和修改。 4、 有利于后端技术部⻔的统⼀规范的标准制定不会出现稀奇古怪的返回内容。 我们之前是使用一个对象来作为 返回格式的标准。但是还是有那么一点丁麻烦的 我们还有更简单的做法 举个例子 就是开惯手动挡的车觉得还行。 但是开过自动挡车很容易就回不去了。 因为 自动挡实在是香 再往后看N年以后出现自动驾驶的汽车我们也就该彻底 “堕落” 了。。。。 程序也是一样的它也在不断的进化 之前。我们刚学的时候比较菜嘛。 老老实实的每个方法都去自己实现一个 HashMap搞得自己很累很憔悴。 然后呢后面能力得到的提升把 它给封装起来只需要去new一个对象就行了。不再需要我们去手动实现了。 但是依然觉得不是那么爽。 学到当前这一块之前是怎么做的现在还是这么做的。【“ 大道至简”】 就比如说登录的时候本来就只需要返回 true或者 false。 那么我就只返回 true / false就行了。 我呢会拦截这个 true 和 false并将这个 true / false 填充到 data 里面。 再去封装好让前端能够识别 的 统一的对象这是不是很爽 这样做开发者就不需要关注到底返回的是一个什么格式的数据给前端。 对于前端来说都一样。我按到的数据格式是不变的。 中间的处理就是由统一功能去处理的。 统⼀数据返回格式的实现
统⼀的数据返回格式可以使⽤ ControllerAdvice ResponseBodyAdvice 的⽅式实现。 类上加 ControllerAdvice 。并且该类实现 ResponseBodyAdvice 接口。必须重写 里面的 supports 和 beforeBodyWrite 方法。supports支持当它返回 true就表示要对 返回的数据进行 格式的重写。反之当它返回 false就不需要重写了。 当需要 到 重写就会进入 beforeBodyWrite 方法。 beforeBodyWrite 方法的意义就是将数据返回之前要不要进行重写 响应数据。 下面来验证一下效果 抓包的结果显示 返回的响应是 JSON 类型的
我们再来试一下用户名密码 不匹配的情况
我们再来写一个极其简单的伪代码。等等我好像还没有演示 supports 方法 返回 false 是否还会触发重写。 搞起
总结 经过上述的练习。 我们可以发现 统一功能处理 是存在缺陷的就是 返回数据的信息描述被写死了。 因为都是统一的格式所以返回的键值对 的 键值 是无法改变的。 换句话来说统一带来的问题就是牺牲了 “ 灵活 ” 所以关于统一功能的使用还是需要根据实际情况来决定
最后补充一点ControllerAdvice 源码分析 - 了解
大家其实回想一下 第二个功能异常 和 第三个功能返回数据的格式其实都是事件啊 我们代码出现一个异常这就是一个异常事件啊 事件发生了我们是可以感知到的。 感知到了之后就可以根据感知到的事件的处理方法敲自己的业务代码。 这样的话如果感知到事件我们写代码就能起到作用了。 异常是这样返回统一的数据格式也是这样的 每一次返回一个数据给前端的时候它也是一个事件数据传输事件。 事件发生了我们的程序是能感知到的。所以才能做统一额处理。
说白了ControllerAdvice注解就是针对项目中发生的事件做拦截的。
通过对 ControllerAdvice 源码的分析我们可以知道上⾯统⼀异常和统⼀数据返回的执⾏流程我们先从 ControllerAdvice 的源码看起点击 ControllerAdvice 实现源码如下 从上述源码可以看出 ControllerAdvice 派⽣于 Component 组件⽽所有组件初始化都会调⽤ InitializingBean 接⼝。 所以接下来我们来看 InitializingBean 有哪些实现类 在查询的过程中我们发现了 其中 Spring MVC 中的实现⼦类是 RequestMappingHandlerAdapter 它⾥⾯有⼀个⽅法 afterPropertiesSet() ⽅法表示所有的参数设置完成之后执⾏的⽅法。 如下图所示 ⽽这个⽅法中有⼀个 initControllerAdviceCache ⽅法查询此⽅法的源码如下 我们发现这个⽅法在执⾏是会查找使⽤所有的 ControllerAdvice 类这些类会被容器中但发⽣某个事件时调⽤相应的 Advice ⽅法。 ⽐如 返回数据前调⽤统⼀数据封装⽐如发⽣异常是调⽤异常的Advice ⽅法实现。
