专有云datav代理踩坑

问题描述

datav开发完成之后，发布是通过在datav页面点击发布后获得发布链接，

一般情况下都是通过直接访问发布链接的方式进行页面访问，但是在一些特定的场景下会需要将这个地址进行代理后再进行访问，项目上碰到的场景是这样的

1. datav版本为专有云datav版本，部署在内网服务器上，并且没有进行互联网透出
   
2. 部分页面需要通过互联网方式进行访问
   

解决过程

默认情况下datav的访问链路为

想要开通公网访问的话，最直接的方式就是配置一个映射代理，链路如下：

这个映射配置比较简单，很快我们就配置完成了，但是在随之后的验证中发现了一个致命的问题导致页面无法正常访问：

1. 互联网映射域名和内网的DataV服务的域名不一致
   
2. DataV服务的域名是通过配置的方式硬编码在了配置文件里，没有根据当前实际访问的代理域名地址对对应的资源文件进行替换或者使用相对路径进行访问
   

以上两点直接导致的后果是：DataV服务没有办法被代理！

问题到这里似乎无解了，除非是互联网映射的域名保持和内网访问的域名一致，这个申请下来又是需要不少的时间，在与DataV研发团队的沟通中，我们摸索出了另外一条路：

在这里的nginx，不仅仅是转发的功能而已，还用到了它的插件sub_filter，简而言之，就是在转发的时候查找和替换对应的文本，这个插件是需要单独编译安装的，安装完成后，对nginx进行配置，核心点在于配置需要替换的文本

          proxy_set_header Accept-Encoding "";
          sub_filter '待替换的文本' '替换后的文本';
          sub_filter_types  css/html;
          sub_filter_once off;

同时这里也需要注意一个坑，当接收请求需要压缩的时候 Accept-Encoding配置为gzip时，sub_filter替换会失效，所以在这里增加了一个配置proxy_set_header Accept-Encoding "";  声明不进行压缩。

至此，页面已经能够通过代理的方式进行访问。

后续

在发布的datav页面开启token校验的时候，此时会涉及到页面的Cookie的设置，因为我们上面是通过nginx进行了一次代理，就需要增加nginx的配置proxy_cookie_domain 代理前的域名 代理后的域名; 来实现前后端cookie域名转换，保证顺利传递。