接入公司开发平台---疑难杂症

功能背景

应安全要求，需要将C端接口都接入公司的开放平台，本来走的好好自己网关的链路，这tm就是硬接

商城C端旧流程

以前C端接口，都走自身zuul网关,不会与开放平台接入，只需要关注自身zuul网关即可

C端旧接口流程图

图片说明

接入后C端接口流程图

// todo

接入开放平台

问题1： C端太多接口了，一个一个加，比较麻烦，对后续有新的C端接口也需要每次都走一遍这样的流程？
问题2： 接入开放平台后，是否影响到现有网关的逻辑？
问题3： CAS / ECAS 对本次接入开放平台有多大的影响？

处理方案

让运维在nginx上添加我们api-uat.kyemall.com -> 跳到我们网关的ip地址；
需要基础服务那边类似添加网关的形式添加 (此操作是让基础服务那边开放平台对我们配死的url进行转发到我们网关)；
```
   openApi:
     path: /openApi/forwardUrl
     serviceId: gateway
```
我们接收到ec.c.auth.openApi.forwardUrl这个apiCode的接口实际都是到我们网关来，通过请求头中的openApiCUrl 和 openApiMethod ，才是实际访问的url和请求方式。

遇到的各种各样的问题

通过ec.c.auth.openApi.forwardUrl访问时，出现您尚未开通此功能，如有需要，请录权限申请，该解决方案，在处理方案2解决；
x-from头在cas/ecas 和ec系统同时被使用到，而且cas/ecas是一个数字类型，而ec系统则是字符串类型，吐血！！！！，只能我们x-from传递数字类型，来兼容那边；

在有token的情况下，访问接口出现您尚未开通此功能，如有需要，请录权限申请，因为开放平台，认为有token都会进行校验，这个时候开放平台会调我们auth服务的一个鉴权的接口，会校验是否是B端接口，但是此时会出现数组越界的问题。以下代码，以前的api-user类似对应服务的，分割出来必然会取出【1】,对应服务名，但是现在是gateway,分割出来只有一个，因此对gateway特殊处理即可。

     // 获取服务名 ，针对的是 api-service的形式
     public static String getUrlPrefix(String serviceCode) {
         for (ServiceCode sc : ServiceCode.values()) {
             if (sc.serviceCode.equals(serviceCode)) {
                 return sc.urlPrefix;
             }
         }
         return "/api/ec/b/" + serviceCode.split("[-]")[1];
     }
    // 如果是网关gateway 那么不用校验
     if (EcAuthInterface.SERVICE_NAME_GATEWAY.equals(authVerify.getServiceCode())) {
         resp.setCode(ResponseCode.RESOURCE_NOT_FOUND.getCode());
         resp.setMsg(ResponseCode.RESOURCE_NOT_FOUND.getMessage());
         return resp;
     }

一个比较大的坑

流程图如下

小说明： cas虽然都是短token，但是还是会通过登录端来区分是正式员工还是临时员工，这是真的服气！！！因为能够确定的是，通过跨声登录的都是会是私人手机，我们通过data.employee.get接口拿到的手机号也是私人手机，因此可以这么搞，而通过司机登录的属于临时员工也是id->对应唯一手机号，只能这么去拿到手机号。