同一个Controller的所有接口方法映射路径的前缀都包含了/pass
我们在类上通过注解@ReqeustMapping
标记映射路径/pass
,这样所有的接口方法前缀都包含了/pass
,并且以致于后面要修改映射路径前缀时只需改这一块地方即可
这也是我们使用SpringMVC最常见的用法
那么,我们的自定义注解也可不可以这样做呢?先无中生有个需求
假设PassController中所有接口都是要进行防刷处理的,并且他们的x, y, z值就一样
如果我们的自定义注解还是只能加载方法上的话,一个一个接口加,那么无疑这是一种很呆的做法
要改的话,其实也很简单,首先是修改自定义注解,让其可以作用在类上
接着就是修改AccessLimitInterceptor
的处理逻辑
AccessLimitInterceptor
中代码修改的有点多,主要逻辑如下
与之前实现比较,不同点在于x, y, z的值要首先尝试在目标类中获取
其次,一旦类中标有此注解,即代表此类下所有接口方法都要进行防刷处理
如果其接口方法同样也标有此注解,根据就近优先原则,以接口方法中的注解标明的值为准
/** * @author: Zero * @time: 2023/2/14 * @description: 接口防刷拦截处理 */ @Slf4j public class AccessLimintInterceptor implements HandlerInterceptor { @Resource private RedisTemplate<String, Object> redisTemplate; /** * 锁住时的key前缀 */ public static final String LOCK_PREFIX = "LOCK"; /** * 统计次数时的key前缀 */ public static final String COUNT_PREFIX = "COUNT"; public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 自定义注解 + 反射 实现, 版本 2.0 if (handler instanceof HandlerMethod) { // 访问的是接口方法,转化为待访问的目标方法对象 HandlerMethod targetMethod = (HandlerMethod) handler; // 获取目标接口方法所在类的注解@AccessLimit AccessLimit targetClassAnnotation = targetMethod.getMethod().getDeclaringClass().getAnnotation(AccessLimit.class); // 特别注意不能采用下面这条语句来获取,因为 Spring 采用的代理方式来代理目标方法 // 也就是说targetMethod.getClass()获得是class org.springframework.web.method.HandlerMethod ,而不知我们真正想要的 Controller // AccessLimit targetClassAnnotation = targetMethod.getClass().getAnnotation(AccessLimit.class); // 定义标记位,标记此类是否加了@AccessLimit注解 boolean isBrushForAllInterface = false; String ip = request.getRemoteAddr(); String uri = request.getRequestURI(); long second = 0L; long maxTime = 0L; long forbiddenTime = 0L; if (!Objects.isNull(targetClassAnnotation)) { log.info("目标接口方法所在类上有@AccessLimit注解"); isBrushForAllInterface = true; second = targetClassAnnotation.second(); maxTime = targetClassAnnotation.maxTime(); forbiddenTime = targetClassAnnotation.forbiddenTime(); } // 取出目标方法中的 AccessLimit 注解 AccessLimit accessLimit = targetMethod.getMethodAnnotation(AccessLimit.class); // 判断此方法接口是否要进行防刷处理 if (!Objects.isNull(accessLimit)) { // 需要进行防刷处理,接下来是处理逻辑 second = accessLimit.second(); maxTime = accessLimit.maxTime(); forbiddenTime = accessLimit.forbiddenTime(); if (isForbindden(second, maxTime, forbiddenTime, ip, uri)) { throw new CommonException(ResultCode.ACCESS_FREQUENT); } } else { // 目标接口方法处无@AccessLimit注解,但还要看看其类上是否加了(类上有加,代表针对此类下所有接口方法都要进行防刷处理) if (isBrushForAllInterface && isForbindden(second, maxTime, forbiddenTime, ip, uri)) { throw new CommonException(ResultCode.ACCESS_FREQUENT); } } } return true; } /** * 判断某用户访问某接口是否已经被禁用/是否需要禁用 * * @param second 多长时间 单位/秒 * @param maxTime 最大访问次数 * @param forbiddenTime 禁用时长 单位/秒 * @param ip 访问者ip地址 * @param uri 访问的uri * @return ture为需要禁用 */ private boolean isForbindden(long second, long maxTime, long forbiddenTime, String ip, String uri) { String lockKey = LOCK_PREFIX + ip + uri; //如果此ip访问此uri被禁用时的存在Redis中的 key Object isLock = redisTemplate.opsForValue().get(lockKey); // 判断此ip用户访问此接口是否已经被禁用 if (Objects.isNull(isLock)) { // 还未被禁用 String countKey = COUNT_PREFIX + ip + uri; Object count = redisTemplate.opsForValue().get(countKey); if (Objects.isNull(count)) { // 首次访问 log.info("首次访问"); redisTemplate.opsForValue().set(countKey, 1, second, TimeUnit.SECONDS); } else { // 此用户前一点时间就访问过该接口,且频率没超过设置 if ((Integer) count < maxTime) { redisTemplate.opsForValue().increment(countKey); } else { log.info("{}禁用访问{}", ip, uri); // 禁用 redisTemplate.opsForValue().set(lockKey, 1, forbiddenTime, TimeUnit.SECONDS); // 删除统计--已经禁用了就没必要存在了 redisTemplate.delete(countKey); return true; } } } else { // 此用户访问此接口已被禁用 return true; } return false; } }
好了,这样就达到我们想要的效果了
项目通过Git还原到"【自定义注解+反射实现接口自由-版本2.0】"版本即可得到此案例实现,自己可以测试万一下
这是目前来说比较理想的做法,至于其他做法,暂时没啥了解到
时间逻辑漏洞
这是我一开始都有留意到的问题
也是一直搞不懂,就是我们现在的所有做法其实感觉都不是严格意义上的x秒内y次访问次数
特别注意这个x秒,它是连续,任意的(代表这个x秒时间片段其实是可以发生在任意一个时间轴上)
我下面尝试表达我的意思,但是我不知道能不能表达清楚
假设我们固定某个接口5秒内只能访问3次,以下面例子为例
底下的小圆圈代表此刻请求访问接口
按照我们之前所有做法的逻辑走
- 第2秒请求到,为首次访问,Redis中统计次数为1(过期时间为5秒)
- 第7秒,此时有两个动作,一是请求到,二是刚刚第二秒Redis存的值现在过期
- 我们先假设这一刻,请求处理完后,Redis存的值才过期
- 按照这样的逻辑走
- 第七秒请求到,Redis存在对应key,且不大于3, 次数+1
- 接着这个key立马过期
- 再继续往后走,第8秒又当做新的一个起始,就不往下说了,反正就是不会出现禁用的情况
按照上述逻辑走,实际上也就是说当出现首次访问时,当做这5秒时间片段的起始
第2秒是,第8秒也是
但是有没有想过,实际上这个5秒时间片段实际上是可以放置在时间轴上任意区域的
上述情况我们是根据请求的到来情况人为的把它放在【2-7】,【8-13】上
而实际上这5秒时间片段是可以放在任意区域的
那么,这样的话,【7-12】也可以放置
而【7-12】这段时间有4次请求,就达到了我们禁用的条件了
是不是感觉怪怪的
想过其他做法,但是好像严格意义上真的做不到我所说的那样(至少目前来说想不到)
之前我们的做法,正常来说也够用,至少说有达到防刷的作用
后面有机会的话再看看,不知道我是不是钻牛角尖了
路径参数问题
假设现在PassController
中有如下接口方法
也就是我们在接口方法中常用的在请求路径中获取参数的套路
但是使用路径参数的话,就会发生问题
那就是同一个ip地址访问此接口时,我携带的参数值不同
按照我们之前那种前缀+ip+uri拼接的形式作为key的话,其实是区分不了的
下图是访问此接口,携带不同参数值时获取的uri状况
这样的话在我们之前拦截器的处理逻辑中,会认为是此ip用户访问的是不同的接口方法,而实际上访问的是同一个接口方法
也就导致了【接口防刷】失效
接下来就是解决它,目前来说有两种
- 不要使用路径参数
这算是比较理想的做法,相当于没这个问题
但有一定局限性,有时候接手别的项目,或者自己根本没这个权限说不能使用路径参数
- 替换uri
- 我们获取uri的目的,其实就是为了区别访问接口
- 而把uri替换成另一种可以区分访问接口方法的标识即可
- 最容易想到的就是通过反射获取到接口方法名称,使用接口方法名称替换成uri即可
- 当然,其实不同的Controller中,其接口方法名称也有可能是相同的
- 实际上可以再获取接口方法所在类类名,使用类名 + 方法名称替换uri即可
- 实际解决方案有很多,看个人需求吧
真实ip获取
在之前的代码中,我们获取代码都是通过request.getRemoteAddr()
获取的
但是后续有了解到,如果说通过代理软件方式访问的话,这样是获取不到来访者的真实ip的
至于如何获取,后续我再研究下http再说,这里先提个醒
总结
说实话,挺有意思的,一开始自己想【接口防刷】的时候,感觉也就是转化成统计下访问次数的问题摆了。后面到网上看别人的写法,又再自己给自己找点问题出来,后面会衍生出来一推东西出来,诸如自定义注解+反射这种实现方式。
以前其实对注解 + 反射其实有点不太懂干嘛用的,而从之前的数据报表导出,再到基本权限控制实现,最后到今天的【接口防刷】一点点来进步去补充自己的知识点,而且,感觉写博客真的是件挺有意义的事情,它会让你去更深入的了解某个点,并且知识是相关联的,探索的过程中会牵扯到其他别的知识点,就像之前的写的【单例模式】实现,一开始就了解到懒汉式,饿汉式
后面深入的话就知道其实会还有序列化/反序列化,反射调用生成实例,对象克隆这几种方式回去破坏单例模式,又是如何解决的,这也是一个进步的点,后续为了保证线程安全问题,牵扯到的synchronized,voliate关键字,继而又关联到JVM,JUC,操作系统的东西。