專有雲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域名轉換，保證順利傳遞。