Initial commit
This commit is contained in:
Docker7530
@@ -0,0 +1,335 @@
|
||||
# 背景介绍
|
||||
|
||||
信安信息可以简单理解为域名及其所属公司的基本信息，这些信息来源于新建域名时上传的附件中所填写的内容。信安信息校验是指 IBS 系统对客户在新建域名时上传附件中的字段信息进行核验。而信安信息同步则是将域名的信安信息从 IBS 系统同步至中国移动 CDN 信安系统（即 CU 系统）。
|
||||
|
||||
信安相关业务主要包括以下三个方面：
|
||||
|
||||
1. **信安附件的上传、解析与校验**：对客户提供的信安附件进行上传与解析，并核验信息的完整性与准确性。
|
||||
2. **信安附件的下载**：提供信安附件的下载功能，便于信息的查阅和备份。
|
||||
3. **信安信息的同步**：将校验后的信安信息同步到 CU 系统，确保系统间的数据一致性。
|
||||
|
||||
# 信安附件的上传、解析与校验
|
||||
|
||||
信安信息的上传、解析与校验的入口不同工单是不一样的。
|
||||
|
||||
大致分为**运营操作工单**是一个接口地址，**业务操作工单**是一个接口地址。
|
||||
|
||||
## 运营操作工单
|
||||
|
||||
### 1、接口位置
|
||||
|
||||
```java
|
||||
/workorder/requestDomain/upload
|
||||
com.cmcc.cdn.platform.selfservice.controller.NewWorkOrderController#requestDomainUpload
|
||||
```
|
||||
|
||||
### 2、附件解析
|
||||
|
||||
IBS 项目中，有一个函数将域名上传的 excel 附件转为 String 字符串，如下：
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.common.util.ExcelUtil#convertToObjectFromExcel(java.io.InputStream, java.util.List<java.lang.String>, java.util.List<java.lang.String>)
|
||||
```
|
||||
|
||||
核心函数是 `analysisExcelFile`，其中的 `checkExcelFormat` 函数是校验 Excel 表头的函数。
|
||||
|
||||
`analysisExcelFile` 校验 Excel 附件大致的逻辑是：先通过 checkExcelFormat 函数提取并校验 excel 表头是否和 Contents 中记录的表头相同，如果不相同，直接返回 false，表示附件解析失败，否则一条条读取 excel 的每一行进行解析。
|
||||
|
||||
`@SecurityExcelAnalysis` 注解（`convertToObjectFromExcel` 函数上）
|
||||
|
||||
IBS6.3.1 版本迭代增加，这个主要是在解析信安附件的时候判断附件中填写的业务类型是否为直播，如果是直播且用户没有填写回源地址的话，IBS 后台去华为云那边查询回源地址并填写，或者自动补齐回源地址为加速域名。
|
||||
|
||||
因为原来回源地址是必填项，但是 IBS6.3.1 直播业务的回源地址可以不填写，会导致上层在取值时如果不去校验是否会空的话，会导致出现空指针异常，因此，这个 AOP 的作用就是当用户没有填写直播业务的域名的回源地址时，后台这边给它补齐，用于通过上层校验。
|
||||
|
||||
### 3、附件校验
|
||||
|
||||
信安附件校验场景（域名配置需求和cache+域名配置），地址： https://kdocs.cn/l/cp84H09h2t89
|
||||
|
||||
核心信安信息校验函数
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.InformationSecurityTableManagerImpl#validateInformationSecurityInfo
|
||||
```
|
||||
|
||||
历史流程：[校验流程图](https://www.processon.com/diagraming/63c5d31e2a93473cd86b7759)
|
||||
|
||||
## 业务操作工单（页面）
|
||||
|
||||
|
||||
|
||||
### 1、接口位置
|
||||
|
||||
```java
|
||||
/order/security/upload
|
||||
com.cmcc.cdn.platform.selfservice.controller.OrderController#uploadSecurity
|
||||
```
|
||||
|
||||
### 2、附件校验
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.PortalInformationServiceImpl#validateAndSaveInfo
|
||||
```
|
||||
|
||||
试用单、试用变更单以及非首次开通的业务单在 IBS 界面上传的信安附件的校验
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BatchSelfDomainServiceImpl#checkXinAnExcelFromIBS
|
||||
```
|
||||
|
||||
> 在 IBS 界面上传的试用单、试用变更单、业务单的信安附件，通过校验之后，信安附件结果存储至表 information_self_domain。
|
||||
|
||||
## BPM 回调可承接之后从 BBOSS 拉取信安附件并校验
|
||||
|
||||
用户在集客大厅上传的信安附件在 BPM 回调试用可承接之后，再对信安附件中的信息进行校验，这里的信安信息校验涉及到试用单、试用变更单以及业务单。
|
||||
|
||||
### 1、试用单信安附件拉取以及校验
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.TestOrderServiceImpl#checkAndSaveInformationSecurityTable
|
||||
```
|
||||
|
||||
该函数中的核心校验代码为：batchSelfDomainService.checkXinAnExcelFromIBS(vos, false);
|
||||
|
||||
### 2、试用变更单信安附件拉取以及校验
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.TestOrderChangeServiceImpl#checkAndSaveXinanTableFromTestChange
|
||||
```
|
||||
|
||||
该函数中的核心校验代码为：batchSelfDomainService.checkXinAnExcelFromIBS(vos, false);
|
||||
|
||||
### 3、业务受理工单信安附件拉取以及校验
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BusinessOrderServiceImpl#checkAndSaveXinanTableFromOrder
|
||||
```
|
||||
|
||||
> 信安信息校验通过之后会存储至表 information_self_domain
|
||||
|
||||
## 前置校验 - 拉取 BBOSS 信安附件并校验及存储
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.PreCheckServiceImpl#checkInfoSecurityTable
|
||||
```
|
||||
|
||||
> 当信安附件校验通过之后，也存储至 information_self_domain 表中。
|
||||
|
||||
# 信安附件下载
|
||||
|
||||
## 域名详情页
|
||||
|
||||
|
||||
|
||||
```java
|
||||
/configManage/getSecurity
|
||||
com.cmcc.cdn.platform.selfservice.controller.ConfigManageController#getInformationSecurity
|
||||
```
|
||||
|
||||
该接口在 ibs 界面如图所示，进入业务运维 - 配置管理界面，点击“下载已上传的附件”
|
||||
|
||||
## 位置二
|
||||
|
||||
```java
|
||||
/download/exportFile
|
||||
com.cmcc.cdn.platform.selfservice.controller.HttpFileController#exportFile
|
||||
```
|
||||
|
||||
这个接口主要是在 IBS 页面下载 BBOSS 那边传的附件的接口（个人认为是试用单页面）。
|
||||
|
||||
# 信安信息同步
|
||||
|
||||
> 每 1 分钟会扫描上报一次删除，上报后需要等工信部反馈结果后，信安系统才会删除本地数据
|
||||
> 工信部对上报数据的解析是自动的，正常情况下 1 分钟内就会有反馈
|
||||
> 新增和修改是每天定时（晚上 23 点）上报
|
||||
|
||||
## 信安同步底层代码
|
||||
|
||||
信安的同步主要分为企业信安的同步和域名信安的同步。
|
||||
|
||||
所谓企业信安也就是企业的基本信息，包括企业名，企业地址，企业单位编码等；
|
||||
|
||||
所谓域名信安指的就是域名的基本信息，包括域名，回源地址，分发省份等。
|
||||
|
||||
根据同步的操作不同，可以分为同步新增和同步修改，因此主要有以下四个函数。
|
||||
|
||||
### 1、同步企业新增信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BigCloudBasicInfoServiceImpl#createInfomationUser
|
||||
```
|
||||
|
||||
首先获取信安 token，然后向信安系统发起新建企业信安信息的请求，将获取的响应存储至 information_user 表中，其中 information_user 表中的 user_id_cdn 为企业的唯一标识，同步到信安系统的企业名称以及表中所存储的企业名称为附件中填写的企业名称。
|
||||
|
||||
### 2、同步企业修改信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BigCloudBasicInfoServiceImpl#updateInfomationUser
|
||||
```
|
||||
|
||||
这个函数的大致逻辑是，首先获取信安 token，然后向信安系统发起修改企业信安信息的请求，将获取的响应存储至 information_user 表中，其中 information_user 表中的 user_id_cdn 为企业的唯一标识
|
||||
|
||||
### 3、同步域名新增信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BigCloudBasicInfoServiceImpl#addInformationDomainInfo
|
||||
```
|
||||
|
||||
这个函数的大致逻辑是，首先获取信安 token，然后向信安系统发起同步域名新增信安信息的请求，将获取的响应存储至表 big_cloud_information_domain 中，其中表 big_cloud_information_domain 中的 domain_id_cdnsys 为域名的唯一标识
|
||||
|
||||
### 4、同步域名修改信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BigCloudBasicInfoServiceImpl#updateInformationDomainInfo
|
||||
```
|
||||
|
||||
### 5、删除域名同步信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BigCloudBasicInfoServiceImpl#deletedInformationDomainInfo
|
||||
```
|
||||
|
||||
根据域名 id（domain_id_cdnsys）去删除，删除 big_cloud_information_domain 表
|
||||
|
||||
### 6、删除企业同步信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.BigCloudBasicInfoServiceImpl#deletedInformationUser
|
||||
```
|
||||
|
||||
根据企业 id（user_id_cdn）去删除，并删除企业下所有域名的信安信息，删除 information_user 以及 big_cloud_information_domain 表
|
||||
|
||||
## 封装代码
|
||||
|
||||
### 同步新增企业以及域名信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.PortalInformationServiceImpl#createOrUpdateInfo
|
||||
```
|
||||
|
||||
通过调用上述四个信安同步底层函数写的同步新增信安或同步修改信安的函数。
|
||||
|
||||
一般很多工单在同步的时候不会直接调用上述四个信安同步底层函数，而直接调用这两个函数。
|
||||
|
||||
这个函数主要做了新增或修改企业信安，新增或修改域名信安，主要用于用户第一次上传信安附件或者域名第一次同步信安时，可以调用该函数。
|
||||
|
||||
### 同步新增或修改域名信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.PortalInformationServiceImpl#updateDomainInformation
|
||||
```
|
||||
|
||||
这个函数主要做了新增或修改域名信安，主要是用于，当域名的信安信息已经在 BigCloudInformationDomain 中存在，则表明域名已在信安系统备案，直接同步修改信安即可。
|
||||
|
||||
### 删除域名企业信安
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.PortalInformationServiceImpl#notifyDeleteInformation
|
||||
```
|
||||
|
||||
## 不同工单的不同位置
|
||||
|
||||
### cache+ 域名配置工单
|
||||
|
||||
在第一步运营经理提交 cache+ 域名配置工单的时候，即运营经理点击提交的时候。
|
||||
|
||||
```java
|
||||
# 自助
|
||||
com.cmcc.cdn.platform.selfservice.manager.WorkOrderManager#handleCacheDomainXinAnInfo
|
||||
# 定制化
|
||||
com.cmcc.cdn.platform.selfservice.service.CacheWorkOrderServiceImpl#cacheDomainIcpUpdateSyncProcess
|
||||
```
|
||||
|
||||
### esop 政企客户经理提交的域名配置需求工单新增域名
|
||||
|
||||
政企客户经理提交的域名配置需求工单新增域名也是在第一步提交域名配置需求工单的时候。
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.order.WorkOrderServiceImpl#saveCustomWorkOrder
|
||||
```
|
||||
|
||||
### 新增直播域名工单（已取消此类型工单）
|
||||
|
||||
新增直播域名工单在运营经理新建工单点击提交之后就校验备案号并同步信安了，新增直播域名工单也是走的队列下发，直播域名同步时分发省份固定为全国。
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.rabbitmq.consumer.LiveIcpConsumer#handle
|
||||
```
|
||||
|
||||
### 信安补录工单
|
||||
|
||||
运营经理提交信安补录工单成功之后即将域名的信安信息同步到信安系统中去了。
|
||||
|
||||
信安补录工单的功能比较单一，其用处就是在于，当域名信安信息缺少时，可以通过运营经理（线上的话还可以通过超管账号）提交信安补录工单，将需要修改或者补充的域名信安信息同步到信安系统中去。
|
||||
|
||||
```java
|
||||
/information/order/submit
|
||||
com.cmcc.cdn.platform.selfservice.controller.InformationController#submit
|
||||
```
|
||||
|
||||
调用链
|
||||
|
||||
submit -> createInformationWorkOrder -> createFrom -> checkUpInformation -> checkUnitXinan
|
||||
|
||||
### 试用单、试用变更单、业务单同步信安（老流程）
|
||||
|
||||
试用单、试用变更单、业务单老流程（即 6.3.1 版本对接 BPM 之前的流程）是在运营经理在业务运维 - 配置管理界面，点击配置域名的时候会同步信安。其实也不一定仅仅指的是这三个单子，对于那些在业务运维 - 配置管理界面点击配置的域名都会再次同步信安，无论这个域名在工单提交的时候有没有同步过信安。这样其实有的域名会同步两次信安了，其实，之前工信部那边要求未下发的域名也需要同步信安，所以域名会同步两次，同步信安也需要分为两步，第一步是域名同步新增信安，第二步是域名同步修改信安。
|
||||
|
||||
```java
|
||||
/configManage/update/config
|
||||
com.cmcc.cdn.platform.selfservice.controller.ConfigManageController#update(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse, java.lang.Boolean, com.cmcc.cdn.platform.selfservice.pojo.SelfServiceDomainConfigVO, org.springframework.validation.BindingResult)
|
||||
```
|
||||
|
||||
自助域名点击配置后同步信安
|
||||
|
||||
|
||||
|
||||
定制化域名点击配置后同步信安
|
||||
|
||||
在 updateConfig->offlineDomainHandle 函数中
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.ConfigManageServiceImpl#offlineDomainHandle
|
||||
```
|
||||
|
||||
### 试用单、试用变更单、业务单同步信安（新流程）
|
||||
|
||||
IBS6.3.1 版本点播域名对接 BPM 之后，试用单、试用变更单、业务单同步信安是在 BPM 验收反馈可承接之后。
|
||||
|
||||
首先，可以统一将试用单、试用变更单、业务单都理解为是从 BBOSS 那边建单的，IBS6.3.1 之后试用单、试用变更单、业务单均对接 BPM，其中试用单、试用变更单以及非首次开通的业务单对接 BPM 的适配单接口，其下发的记录存储至 `bpm_task` 表；首次开通的业务单对接 BPM 的通用运维单接口，其下发记录存储至 `bpm_dns_task` 表。
|
||||
|
||||
**对于试用单、试用变更单以及非首次开通的业务单对接 BPM 的适配单接口**，其信安同步在
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.bpm.impl.BpmManageServiceImpl#uniCastCallBackProcess
|
||||
```
|
||||
|
||||
这个统一处理函数中，这个统一处理函数做了配置入库、同步信安、日志订阅、同步 crs 的操作。其中同步信安的函数为：`syncXinAn`。
|
||||
|
||||
syncXinAn 函数中试用单，试用变更单以及非首次开通的业务单的同步信安子函数如下所示，这些函数的大致逻辑是，首先去 `information_self_domain` 表中查询是否存在域名信安信息，如果存在则直接取这张表里的数据进行同步，否则就直接取 BBOSS 那边拉取附件进行同步，从 BBOSS 那边拉取信安附件的函数为：
|
||||
|
||||
```java
|
||||
com.cmcc.cdn.platform.selfservice.service.impl.HttpFileServiceImpl#exportAndSaveFileContent
|
||||
```
|
||||
|
||||
对于试用单、试用变更单以及非首次开通的业务单对接 BPM 的适配单接口，其信安同步失败的信息记录在 `bpm_task` 表的 `xin_an_error_msg` 字段；
|
||||
|
||||
对于对于首次开通的业务单对接 BPM 的通用运维单接口，其信安同步失败的结果记录在 `bpm_dns_task` 表的 `xin_an_error_msg` 字段，目前同步失败的结果仅在数据库中记录，因此需要定期安排人员去检查有没有同步失败的域名，如果有的话需要线下调接口再次同步，或者安排运营经理提交信安补录工单，同步失败的结果仅在数据库中记录。
|
||||
|
||||
### 直播控制台 - 自助域名 - 点击配置同步信安
|
||||
|
||||
```
|
||||
/live/config/addPlainInfo
|
||||
com.cmcc.cdn.platform.selfservice.service.live.impl.LiveConfigServiceImpl#manageDomain
|
||||
```
|
||||
|
||||
源于 6.2.0 需求，在 manageDomain 中进行了自助域名修改信安的异步同步。其大致逻辑为，先去华为云那边查询域名的源站信息，然后调用域名修改信安的同步函数 `updateDomainInformation` 将域名信安同步到信安系统中去。
|
||||
|
||||
# 信安接口能力
|
||||
|
||||
新增和删除接口目前最多支持多少数据的同步能力。
|
||||
|
||||
目前一次最多 100 条，后续删除会增加到 1000 条
|
||||
|
||||
# 信安备案号接口优化开关
|
||||
|
||||
XINAN_ICP_OPT_SWITCH
|
||||
@@ -0,0 +1,196 @@
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
【核心判断】
|
||||
|
||||
🔴 这是垃圾代码 - 复杂、低效、有隐藏的递归炸弹
|
||||
|
||||
---
|
||||
【流程分析：a.b.c.tttt.cn 每层都没备案会怎样】
|
||||
|
||||
假设主域名集合包含 cn，那么：
|
||||
|
||||
第1轮：直接查询
|
||||
|
||||
查询: a.b.c.tttt.cn
|
||||
返回: false (未备案)
|
||||
↓
|
||||
计算主域名: tttt.cn
|
||||
生成子域名列表: [b.c.tttt.cn, c.tttt.cn, tttt.cn]
|
||||
进入第2轮 ↓
|
||||
|
||||
第2轮：递归查子域名（第258行的递归陷阱）
|
||||
|
||||
查询: [b.c.tttt.cn, c.tttt.cn, tttt.cn]
|
||||
全部返回: false
|
||||
↓ 分别处理：
|
||||
|
||||
b.c.tttt.cn → 生成 [c.tttt.cn, tttt.cn]
|
||||
c.tttt.cn → 生成 [tttt.cn]
|
||||
tttt.cn → 生成 [] (空！递归终止条件)
|
||||
|
||||
合并后查询列表: [c.tttt.cn, tttt.cn, tttt.cn] ← 注意重复！
|
||||
进入第3轮 ↓
|
||||
|
||||
第3轮：继续递归
|
||||
|
||||
查询: [c.tttt.cn, tttt.cn, tttt.cn] ← tttt.cn被查了2次！
|
||||
全部返回: false
|
||||
↓
|
||||
c.tttt.cn → 生成 [tttt.cn]
|
||||
tttt.cn → 生成 []
|
||||
tttt.cn → 生成 []
|
||||
|
||||
合并后查询列表: [tttt.cn]
|
||||
进入第4轮 ↓
|
||||
|
||||
第4轮：最后一次
|
||||
|
||||
查询: [tttt.cn]
|
||||
返回: false
|
||||
↓
|
||||
tttt.cn → 生成 []
|
||||
|
||||
递归结束！
|
||||
|
||||
最终结果
|
||||
|
||||
icpMap = {
|
||||
"a.b.c.tttt.cn": "false" // 186行的逻辑会用最后一次子域名查询结果覆盖
|
||||
}
|
||||
|
||||
---
|
||||
【致命问题】
|
||||
|
||||
1️⃣ 隐藏的递归炸弹 (XinAnApiService.java:258)
|
||||
|
||||
Map<String, String> domainsICP = getDomainsIcp(subDomains); // 递归！
|
||||
|
||||
这他妈是在干什么？
|
||||
- 方法 getDomainsIcp 调用 getSubDomainIcp
|
||||
- getSubDomainIcp 又调用回 getDomainsIcp
|
||||
- 形成递归，但没有任何注释说明！
|
||||
- 递归深度 = 域名层级数 - 1
|
||||
|
||||
对于 a.b.c.d.e.f.g.tttt.cn（8层域名）：
|
||||
- 会递归 7 次
|
||||
- 总查询次数：1 + 7 + 6 + 5 + 4 + 3 + 2 + 1 = 28 次调用信安接口！
|
||||
- 而且 tttt.cn 会被重复查询 7 次！
|
||||
|
||||
2️⃣ 数据结构错了 - 没有去重！
|
||||
|
||||
List<String> subDomains = Lists.newArrayList();
|
||||
subDomainMap.values().forEach(subDomains::addAll); // 256-257行：直接addAll，没去重！
|
||||
|
||||
tttt.cn 会在 subDomains 列表中出现多次，每次都要查询信安接口。
|
||||
|
||||
"Bad programmers worry about the code. Good programmers worry about data structures."
|
||||
- 你需要的是 Set<String>，而不是 List<String>
|
||||
- 或者在查询前去重：subDomains.stream().distinct().collect(Collectors.toList())
|
||||
|
||||
3️⃣ 复杂度爆炸 - 3层缩进是底线，这代码有多少层？
|
||||
|
||||
看看第147-158行的嵌套：
|
||||
for (Map.Entry<String, String> entry : icpMap.entrySet()) { // 第1层
|
||||
if (StringUtils.isEmpty(icp) || FALSE_ICP.getValue().equals(icp)) { // 第2层
|
||||
if (CollectionUtils.isEmpty(subDomains)) { // 第3层
|
||||
continue;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
还有异常处理里又重复了一遍逻辑（159-170行）—— 这是什么鬼设计？
|
||||
|
||||
4️⃣ getSubDomain 的诡异逻辑 (XinAnApiService.java:358-367)
|
||||
|
||||
temp.forEach(var ->
|
||||
subDomains.addFirst(StringUtils.join(Arrays.asList(var, subDomains.getFirst()), SEPARATOR2))
|
||||
);
|
||||
subDomains.remove(subDomains.getFirst()); // 为什么要先加再删？
|
||||
|
||||
为什么不一开始就不加原域名？
|
||||
- 这是在解决不存在的问题
|
||||
- 应该直接构建正确的列表，而不是"先加后删"
|
||||
|
||||
---
|
||||
【Linus式重构方案】
|
||||
|
||||
核心思想：消除递归，用迭代 + 去重
|
||||
|
||||
public Map<String, String> getDomainsIcp(List<String> domains) {
|
||||
if (CollectionUtils.isEmpty(domains)) {
|
||||
return Maps.newHashMap();
|
||||
}
|
||||
|
||||
// 第1步：收集所有需要查询的域名（包括子域名），用 Set 去重
|
||||
Set<String> allDomainsToQuery = new LinkedHashSet<>();
|
||||
Map<String, List<String>> domainHierarchy = new HashMap<>();
|
||||
|
||||
for (String domain : domains) {
|
||||
allDomainsToQuery.add(domain);
|
||||
String mainDomain = getDomainParam(domain);
|
||||
List<String> subDomains = getSubDomain(mainDomain, domain);
|
||||
allDomainsToQuery.addAll(subDomains); // Set自动去重
|
||||
domainHierarchy.put(domain, subDomains);
|
||||
}
|
||||
|
||||
// 第2步：一次性查询所有域名（去重后）
|
||||
Map<String, String> allIcpResults = queryDomainsIcpByGroup(new ArrayList<>(allDomainsToQuery));
|
||||
|
||||
// 第3步：为每个原始域名找最近的有备案的父域名
|
||||
Map<String, String> result = new HashMap<>();
|
||||
for (String domain : domains) {
|
||||
String icp = allIcpResults.get(domain);
|
||||
|
||||
// 如果自己有备案，直接用
|
||||
if (icp != null && !icp.equals(FALSE_ICP.getValue()) && !icp.isEmpty()) {
|
||||
result.put(domain, icp);
|
||||
continue;
|
||||
}
|
||||
|
||||
// 否则从子域名列表中找第一个有备案的
|
||||
List<String> subDomains = domainHierarchy.get(domain);
|
||||
boolean found = false;
|
||||
if (subDomains != null) {
|
||||
for (String subDomain : subDomains) {
|
||||
String subIcp = allIcpResults.get(subDomain);
|
||||
if (subIcp != null && !subIcp.equals(FALSE_ICP.getValue()) && !subIcp.isEmpty()) {
|
||||
result.put(domain, subIcp);
|
||||
found = true;
|
||||
break;
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
if (!found) {
|
||||
result.put(domain, icp != null ? icp : "");
|
||||
}
|
||||
}
|
||||
|
||||
return result;
|
||||
}
|
||||
|
||||
改进效果：
|
||||
|
||||
| 指标 | 原代码 | 重构后 |
|
||||
|--------------|---------------|-----------|
|
||||
| 递归次数 | N层 | 0 |
|
||||
| 接口调用次数（8层域名） | 28次 | 8次（去重后） |
|
||||
| 重复查询 | 是 | 否 |
|
||||
| 代码行数 | ~80行（分散在3个方法） | ~40行（单方法） |
|
||||
| 可读性 | 需要追踪递归 | 一目了然 |
|
||||
|
||||
---
|
||||
【最后警告】
|
||||
|
||||
这段代码有三个经典反模式：
|
||||
|
||||
1. "聪明"代码 - 递归隐藏在方法调用里，不看完整代码根本发现不了
|
||||
2. 重复逻辑 - 异常处理块里复制粘贴了主逻辑
|
||||
3. 过度抽象 - getSubDomain 方法可以简化成3行，但写成了10行
|
||||
|
||||
"Talk is cheap. Show me the code." - 现在代码给你了,你看着办吧。
|
||||
|
||||
需要我帮你重构吗?还是你有其他问题?
|
||||
```
|
||||
@@ -0,0 +1,33 @@
|
||||
域名备案号查询时，如果对一个完整的域名（例如：`cdn.jiangsu.chinatax.gov.cn`）无法直接获取备案信息，会将其拆分为子域名列表进行逐级查询。例如：
|
||||
|
||||
- 原始域名：`cdn.jiangsu.chinatax.gov.cn`
|
||||
- 切割后的子域名列表：`["jiangsu.chinatax.gov.cn", "chinatax.gov.cn"]`
|
||||
|
||||
通过对这些子域名一次性全部查询备案信息，得到一个备案信息映射：
|
||||
|
||||
```
|
||||
{
|
||||
"chinatax.gov.cn": "true_京ICP备13021685号-2",
|
||||
"jiangsu.chinatax.gov.cn": "true_苏ICP备05002258号-2"
|
||||
}
|
||||
```
|
||||
|
||||
最后为原始域名（`cdn.jiangsu.chinatax.gov.cn`）确定一个最终的备案号。
|
||||
|
||||
逻辑是遍历子域名列表，根据子域名在备案信息映射中是否存在，选取对应的备案号。代码逻辑如下：
|
||||
|
||||
```java
|
||||
subDomainMap.forEach((key, subs) -> subs.forEach(sub -> {
|
||||
if (domainsICP.containsKey(sub)) {
|
||||
result.put(key, domainsICP.get(sub));
|
||||
}
|
||||
}));
|
||||
```
|
||||
|
||||
这里 `subDomainMap` 存储的是原始域名和其对应的子域名列表的映射，例如 `{ "cdn.jiangsu.chinatax.gov.cn": ["jiangsu.chinatax.gov.cn", "chinatax.gov.cn"] }`，`domainsICP` 是备案信息映射，`result` 用于存储最终的备案号结果。
|
||||
|
||||
代码逻辑中，子域名列表 `["jiangsu.chinatax.gov.cn", "chinatax.gov.cn"]` 是按照从长到短的顺序遍历的。由于 `result.put(key, value)` 会覆盖之前的值，最终结果总是会被列表中最后一个匹配到的子域名的备案号覆盖。
|
||||
|
||||
- 第一次循环，`sub` 为 `jiangsu.chinatax.gov.cn`，找到备案号 `true_苏ICP备05002258号-2`，存储到 `result` 中。
|
||||
- 第二次循环，`sub` 为 `chinatax.gov.cn`，也找到备案号 `true_京ICP备13021685号-2`，会覆盖掉之前的值。
|
||||
- 同理如果 `chinatax.gov.cn` 为 `false` 那么最终 `cdn.jiangsu.chinatax.gov.cn` 也会被覆盖为未备案（false）。
|
||||
@@ -0,0 +1,7 @@
|
||||
将信安模板放到线上4台服务器上的制定目录 `/opt/cdn-portal/`
|
||||
|
||||
超管修改配置项：`XINAN_EXCEL_FILE_URL` value: `/opt/cdn-portal/信安导入模板.xls` description:更新信安模板文件路径
|
||||
|
||||
超管调用接口：`/patch/3.8.1/upload/default/file`，获取到新信安模板的md5值
|
||||
|
||||
超管修改配置项：`INFORMATION_SECURITY_EXCEL_FILE_ID` value: 填入上述接口响应的md5值. description:更新信安模板
|
||||
@@ -0,0 +1,9 @@
|
||||
1、1008 校验异常，同一个域名支持多个主体但被校验返回异常（信安临时关闭）
|
||||
|
||||
2、ibs 因企业下只存在一个域名，当发起域名删除时会变为同步企业信息删除。但信安侧未删除域名信安信息。
|
||||
|
||||
3、信安系统到工信部 ftp 删除不稳定，会导致我们删了但是信安系统还有客户咨询为什么。
|
||||
|
||||
4、出现过一次 jyj.jiaozuo.gov.cn 域名查询异常，在信安测处理后查询正常（不知道他们是不是出问题了）
|
||||
|
||||
5、并发认证会失败
|
||||
@@ -0,0 +1,264 @@
|
||||
# 数据核实
|
||||
|
||||
1. 通过数据库表 `big_cloud_information_domain` 和 `information_user` 确认需要处理的信安信息现状，前者为域名信息，后者为企业信息。
|
||||
2. 通过 IBS-信安对接群 与信安侧人员确认要处理的信安信息的存在性，一定要确认好两点：
|
||||
1. 要删除的域名所属的主体下是否只有这一个域名；
|
||||
2. 要删除的主体下的域名是不是预期要删除的所有域名。
|
||||
|
||||
> [!TIP]
|
||||
>
|
||||
> 如果发起企业信安信息删除，会将此企业下的所有域名删除。
|
||||
>
|
||||
> 如果当前域名是此企业下的最后一个域名，应发起企业信安信息删除，否则直接发起域名信安信息删除。
|
||||
|
||||
# 相关接口
|
||||
|
||||
> [!TIP]
|
||||
>
|
||||
> 每个请求接口中添加 Headers（AccessKey : dayun_admin）
|
||||
>
|
||||
> 逻辑未使用但是接口有声明
|
||||
|
||||
## 新增企业信安信息
|
||||
|
||||
```json
|
||||
{{生产}}/v1.0/add_user_info
|
||||
|
||||
{
|
||||
"add_user_info_list": [
|
||||
{
|
||||
"add": "北京市朝阳区东风镇东枫德必 c 栋 1 层 c1",
|
||||
"domain_info": [
|
||||
{
|
||||
"distribute_prov": [
|
||||
"551",
|
||||
"100",
|
||||
"591",
|
||||
"931",
|
||||
"200",
|
||||
"771",
|
||||
"851",
|
||||
"898",
|
||||
"311",
|
||||
"371",
|
||||
"451",
|
||||
"270",
|
||||
"731",
|
||||
"431",
|
||||
"250",
|
||||
"791",
|
||||
"240",
|
||||
"471",
|
||||
"951",
|
||||
"971",
|
||||
"531",
|
||||
"351",
|
||||
"290",
|
||||
"210",
|
||||
"280",
|
||||
"220",
|
||||
"891",
|
||||
"991",
|
||||
"871",
|
||||
"571",
|
||||
"230"
|
||||
],
|
||||
"domain": "vodtest.manlaxy.com",
|
||||
"domain_id_cdnsys": "jERiixMeU_sxtYZt",
|
||||
"introduce_prov": "210",
|
||||
"reg_id": "冀ICP备2022004811号-3",
|
||||
"source_list": [
|
||||
"origin.s.manlaxy.com"
|
||||
],
|
||||
"top_domain": "com",
|
||||
"user_id_cdn": "jERiixMeU"
|
||||
}
|
||||
],
|
||||
"id_number": "91131001MA0ELE1768",
|
||||
"id_type": 1,
|
||||
"officer_email": "",
|
||||
"officer_employee": "刘洋",
|
||||
"officer_id_no": "210404198209082434",
|
||||
"officer_id_type": 2,
|
||||
"officer_mobile": "18910285873",
|
||||
"officer_tel": "",
|
||||
"prov_id_list": [
|
||||
"210"
|
||||
],
|
||||
"unit_name": "廊坊数云科技有限公司",
|
||||
"unit_nature": 4,
|
||||
"user_id_cdn": "jERiixMeU"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 修改企业信安信息
|
||||
|
||||
```json
|
||||
{{生产}}/v1.0/update_user_info
|
||||
|
||||
{
|
||||
"update_user_info_list": [
|
||||
{
|
||||
"id_number": "91310113MA1GL9DG67",
|
||||
"user_id_cdn": "CHDwiJoOf",
|
||||
"unit_name": "上海梦曼网络科技有限公司",
|
||||
"id_type": 1,
|
||||
"unit_nature": 4,
|
||||
"zip_code": "",
|
||||
"add": "上海市闵行区光华路598号",
|
||||
"officer_employee": "陈杰",
|
||||
"officer_id_type": 2,
|
||||
"officer_id_no": "310108199606290015",
|
||||
"officer_tel": "",
|
||||
"officer_mobile": "13817366987",
|
||||
"officer_email": "bob@new1cloud.com",
|
||||
"prov_id_list": [
|
||||
"100"
|
||||
],
|
||||
"deleted": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 删除企业信安信息
|
||||
|
||||
```json
|
||||
{{生产}}/v1.0/delete_user_info
|
||||
|
||||
{
|
||||
"delete_user_info_list": [
|
||||
{
|
||||
"user_id_cdn": "vihrMBFok"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 新增域名信安信息
|
||||
|
||||
```json
|
||||
{{生产}}/v1.0/add_domain_info
|
||||
|
||||
{
|
||||
"add_domain_info_list": [
|
||||
{
|
||||
"domain_id_cdnsys": "DtsPgBHHY_gPUcTP",
|
||||
"domain": "valipl-vip.cp31.ott.cibntv.net.01.hy84739386.cn",
|
||||
"source_list": [
|
||||
"valipl-vip.cp31.ott.cibntv.net.upstream.myalicdn.com"
|
||||
],
|
||||
"reg_id": "京ICP备12001949号-1",
|
||||
"top_domain": "net",
|
||||
"user_id_cdn": "DtsPgBHHY",
|
||||
"distribute_prov": [
|
||||
"551",
|
||||
"100",
|
||||
"591",
|
||||
"931",
|
||||
"200",
|
||||
"771",
|
||||
"851",
|
||||
"898",
|
||||
"311",
|
||||
"371",
|
||||
"451",
|
||||
"270",
|
||||
"731",
|
||||
"431",
|
||||
"250",
|
||||
"791",
|
||||
"240",
|
||||
"471",
|
||||
"951",
|
||||
"971",
|
||||
"531",
|
||||
"351",
|
||||
"290",
|
||||
"210",
|
||||
"280",
|
||||
"220",
|
||||
"891",
|
||||
"991",
|
||||
"871",
|
||||
"571",
|
||||
"230"
|
||||
],
|
||||
"introduce_prov": "996",
|
||||
"cp_domain": "valipl-vip.cp31.ott.cibntv.net"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 修改域名信安信息
|
||||
|
||||
```json
|
||||
{{生产}}/v1.0/update_domain_info
|
||||
|
||||
{
|
||||
"update_domain_info_list": [
|
||||
{
|
||||
"distribute_prov": [
|
||||
"210",
|
||||
"571",
|
||||
"791",
|
||||
"471",
|
||||
"280",
|
||||
"531",
|
||||
"371",
|
||||
"731",
|
||||
"250",
|
||||
"100",
|
||||
"551",
|
||||
"220",
|
||||
"230",
|
||||
"311",
|
||||
"351",
|
||||
"240",
|
||||
"431",
|
||||
"451",
|
||||
"591",
|
||||
"270",
|
||||
"200",
|
||||
"771",
|
||||
"898",
|
||||
"851",
|
||||
"871",
|
||||
"891",
|
||||
"290",
|
||||
"931",
|
||||
"971",
|
||||
"951",
|
||||
"991"
|
||||
],
|
||||
"domain": "sptest.tj.jcy.gov.cn.84.cdnhwcqir15.com",
|
||||
"domain_id_cdnsys": "VFZKhiIyQ_wbhkrW",
|
||||
"introduce_prov": "220",
|
||||
"reg_id": "京ICP备10217144号-1",
|
||||
"source_list": [
|
||||
"test.eos-tianjin-1-internal.cmecloud.cn"
|
||||
],
|
||||
"top_domain": "gov.cn",
|
||||
"user_id_cdn": "VFZKhiIyQ",
|
||||
"cp_domain": "sptest.tj.jcy.gov.cn"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 删除域名信安信息
|
||||
|
||||
```json
|
||||
{{生产}}/v1.0/delete_domain_info
|
||||
|
||||
{
|
||||
"delete_domain_info_list": [
|
||||
{
|
||||
"domain_id_cdnsys": "xdbLMBFMR_RLHYqZ"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
Reference in New Issue
Block a user