网站建设优化两千字,闵行区核酸检测点,学校网站建设规范,张家口百度免费做网站目录
需求简述
设计方案
参考代码
可优化点 需求简述 日常的开发对接过程中#xff0c;经常会遇到需要给其他合作伙伴或者其他系统通过接口的方式提供数据#xff0c;或者有些接口是需要提供通用能力出去的。 从安全的角度考虑#xff0c;我们往往需要给接口加一些安全校…目录
需求简述
设计方案
参考代码
可优化点 需求简述 日常的开发对接过程中经常会遇到需要给其他合作伙伴或者其他系统通过接口的方式提供数据或者有些接口是需要提供通用能力出去的。 从安全的角度考虑我们往往需要给接口加一些安全校验不能让接口裸奔不然任何系统任何人只要网络通就能调用这就很容易有安全隐患。 如何做接口的安全校验 常见的一种方式就是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(secrettimestamp);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(secrettimestamp);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打爆。这里的失效时间可以根据实际情况设计。另外关于时间戳的校验可以再加一层校验根据当前时间判断时间戳是否在指定浮动范围内如果不在哪怕时间戳没有在已请求过时间戳缓存中也直接当做非法请求。 这就能避免过期时间戳重复使用的情况这种优化浮动范围的设置比较关键主要是要求调用方和后端主机的时钟基本同步这个浮动范围就是时钟不同步的最大范围。 ④ 将所有请求按照指定格式记录日志可用于问题分析及调用量分析。 ⑤ 根据业务需要可以加上一些限流策略避免调用方无节制的调用。
