wordpress手机端独立域名seo顾问服务公司

目录

需求简述

设计方案

参考代码

可优化点

---

需求简述

       日常的开发对接过程中，经常会遇到需要给其他合作伙伴或者其他系统通过接口的方式提供数据，或者有些接口是需要提供通用能力出去的。 从安全的角度考虑，我们往往需要给接口加一些安全校验，不能让接口裸奔，不然任何系统任何人只要网络通就能调用，这就很容易有安全隐患。

       如何做接口的安全校验？ 常见的一种方式就是JWT，给调用方分配一个token，调用方调用之前先获取token，调用的时候将token带上，后端校验token是否合法，并做拦截和放通。 但是token通过F12查看请求，或者网络抓包都可以轻松拿到，拿到手，就很容易进行模拟请求，所以这种方案还是不够安全。 

       当然我们也可以通过防火墙的方式，直接限制调用方的IP，这种方式相对简单，但是对于网络环境有要求，并且有实施的复杂度。 

设计方案

       我们在token方案的基础上做一些改造。通过base64编码+不可逆加密以及时间戳校验的方式，增强接口校验的安全性。 

       首先创建一个外部应用表，主要用于存储分配给外部应用的app_code和app_secret，也可以加一些其他字段，比如：备注信息、系统基本信息等。 

       约定所有提供给外部调用的接口，都会先校验请求header中是否带有access_token，并校验access_token的有效性。 

       access_token的生成规则为：base64(app_code|时间戳|app_secret+时间戳))

       服务端会拦截所有外部接口的请求，拿出access_token，进行base64解码，通过|分隔字符串，取出app_code、时间戳、不可逆加密串。 通过app_code到外部应用表查询对应的app_secret，然后根据入参中的时间戳，按照规则生成不可逆的加密串，然后判断加密串是否相等，相等的话就认为请求合法。 

       这里其实还有个细节，那就是这种方案有和前面提到的token方案有什么区别? 如果通过F12或者抓包拿到access_token也同样可以无限制模拟请求了。

       所以，这里我们要对时间戳也加上校验，即一个时间戳有效期只能有一次，拦截器中会记录调用的时间戳，每次请求过来，会先判断时间戳是否已经存在，如果存在，直接判定请求失败，这就能将恶意模拟已请求的拦截住，除非模拟方清晰的知道加密规则以及对应分配给调用方的code和secret信息。

参考代码

       提供一些可参考的代码如下，关于base64以及加密串生成及校验的参考代码如下：

public class InterFaceCheck
{//base64加密public static String base64Encode(String str){return Base64.getEncoder().encodeToString(str.getBytes());}//base64解密public static String base64Decode(String str){byte [] decodeBytes = Base64.getDecoder().decode(str);return new String(decodeBytes);}//md5加密public static String encryptMD5(String str){try {// 创建MD5加密对象MessageDigest md = MessageDigest.getInstance("MD5");// 执行加密操作byte[] messageDigest = md.digest(str.getBytes());// 将字节数组转换为16进制字符串StringBuilder hexString = new StringBuilder();for (byte b : messageDigest) {String hex = Integer.toHexString(0xff & b);if (hex.length() == 1) {hexString.append('0');}hexString.append(hex);}// 返回加密后的字符串return hexString.toString();} catch (Exception e) {throw new RuntimeException(e);}}//生成加密认证，认证规则为：base64(app_code|时间戳|md5(secret+时间戳))public static String getAuth(String appCode,String secret,String timestamp){String secretContent = encryptMD5(secret+timestamp);String authStr = appCode+"|"+timestamp+"|"+secretContent;System.out.println(authStr);return base64Encode(authStr);}//auth检验，样例public static boolean checkAuth(String auth){String authStr = base64Decode(auth);String[] authArr = authStr.split("\\|");if(authArr.length!=3){return false;}String appCode = authArr[0];String timestamp = authArr[1];String secretContent = authArr[2];String secret = "123456"; //实际上这个secret是需要通过appCode去数据库查询得到，并且这里还要将请求出入参进行记录String secretContentNew = encryptMD5(secret+timestamp);if(!secretContent.equals(secretContentNew)){return false;}return true;}public static void main(String[] args){String auth = getAuth("app_code","app_secret","2024-09-10 11:11:00");System.out.println(auth);System.out.println(checkAuth(auth));}

       关于接口认证校验，可以直接使用AOP切面，这个不再赘述了，相关参考代码非常多。

可优化点

       ① 根据app_code查询app_secret可以走缓存，应用启用的时候，将这些信息全部刷入redis，减少不必要的IO操作。

       ② 外部应用配置表可以新增一个IP地址的字段，用于配置调用方的IP白名单，如果开启IP白名单校验了，可以先校验请求方的IP是否在配置的白名单中，如果不在可以直接过滤掉。这种方式也可以实现防火墙的效果，但是对防火墙是松耦合的。

       ③ 时间戳的校验和失效，时间戳写入redis中，设置一个默认失效时间，不然请求过的时间戳随着时间推移会把redis打爆。这里的失效时间可以根据实际情况设计。另外，关于时间戳的校验可以再加一层校验，根据当前时间判断时间戳是否在指定浮动范围内，如果不在，哪怕时间戳没有在已请求过时间戳缓存中，也直接当做非法请求。 这就能避免过期时间戳重复使用的情况，这种优化浮动范围的设置比较关键，主要是要求调用方和后端主机的时钟基本同步，这个浮动范围就是时钟不同步的最大范围。 

       ④ 将所有请求按照指定格式记录日志，可用于问题分析及调用量分析。

       ⑤ 根据业务需要可以加上一些限流策略，避免调用方无节制的调用。