目錄
- 前言
- 困難
- 跨域定義
- nginx 的特性
- 嘗試實現
- 最終效果
- 題外話
前言
我們自己的系統(tǒng)需要加載第三方系統(tǒng)中的一部分組件。計劃的是第三方開發(fā)、提供相關接口,我們通過接口獲取到數據,然后,再用這些數據在我們系統(tǒng)中吧相關的功能實現了
可惜的是,領導沒有協調下來。正規(guī)的途徑搞不定,那就需要花式整活了
前面也說了,我們走接口拉數據重新渲染,這樣的玩法是比較常規(guī)的,缺點是需要重新去實現相關模塊,還需要對方開放接口。
現在只能走非正常渠道,比如,容易想到的,就是 我們直接把頁面嵌入到自己的系統(tǒng),同時需要對第三方頁面的樣式,組件進行控制
困難
上面提到的方法,就是在我們自己的系統(tǒng)里,規(guī)劃一個 iframe,通過 src 屬性引入第三方的系統(tǒng)。
這里一個最大的問題,就是跨域。網絡上提到的最有可能解決的方案,通過 postMessage跨域,可惜,這個還是需要第三方配合
跨域定義
首先狹義的同源就是指,域名、協議、端口均為相同。
跨域,是指瀏覽器不能執(zhí)行其他網站的腳本。它是由瀏覽器的同源策略造成的,是瀏覽器對JavaScript實施的安全限制。
nginx 的特性
反向代理
配置一個 url,用戶如果訪問這個 url ,就能給代理到真實需要的 url
動靜分離
正如字面的意思,動態(tài)的資源(需要服務器進行計算)和靜態(tài)的資源(一般是指 html,css,js,img等靜態(tài)頁面的相關資源)分離開來
嘗試實現
因為我們的 A 應用使用了 80 端口,第三方的 B 系統(tǒng)也使用了 80 端口,那就需要加后綴來區(qū)分代理到 B 系統(tǒng),大致的 url 如下
# A 的 url
http://localhost/
# B 加后綴的 url
http://localhost/three-part
# B 的實際 url
http://172.16.1.1/
我們正常訪問 localhost 會到 A 系統(tǒng)的首頁,訪問 172.16.1.1 會訪問 B 的首頁,如果通過代理的 URL 去訪問,nginx 實際上會給代理到 172.16.1.1/three-part,沒錯,測試的時候,發(fā)現吧后綴給帶過去了?? 不排除我不專業(yè),沒配置到位,但我測試的效果就是這樣
上述配置的思路,就是讓兩個應用同 ip 同端口,然后 A 應用里 iframe 加載了 B 的首頁,那就能通過 js 去操作
很遺憾,那就只有配置成不同的端口了,比如給 B 應用的代理 url 配置為 localhost:81/,這樣一來,無法在 A 應用的 iframe 對應的頁面里,編寫對 B 應用修改的 js 了
最終效果
隨著我對 B 應用的 f12,我發(fā)現,他們封裝了一個 x.min.js ,這個文件登陸的時候會加載,進入首頁后也會加載。
那么,騷操作就來了,我直接重寫他們的這個 js 文件,吧我需要的邏輯安排在文件的最后面,然后,讓頁面在加載這個 x.min.js 的時候,去加載我服務器端修改過后的 js 文件,而不是去加載第三方服務器里的 x.min.js
整個流程的示意圖如下示:
下面就是我配置好正在用的nginx配置
upstream mir{
server 10.1.128.58:80;
}
server {
listen localhost:8001; # nginx 需要監(jiān)聽的 url及對應的端口
location =/static/mir.min.js {
root C:/r9/bin/resources;
}
location / {
# 可以理解為這里用了一個 url 的變量名,這個變量名定義在 upstream 中
proxy_pass http://mir;
# 下面幾項算是跨域標配,直接抄上就行
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Fonwarded-For $proxy_add_x_forwarded_for;
if ($request_method = 'OPTIONS') {
return 204;
}
}
# 靜態(tài)資源放行
location ~ \.(gif|jpg|jpeg|css|js|svg)$ {
proxy_pass http://mir;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Fonwarded-For $proxy_add_x_forwarded_for;
expires 30d;
}
# 添加跨域請求頭
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow_Credentials' 'true';
add_header 'Access-Control-Allow-Headers' 'Authorization,Accept,Origin,DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE,PATCH';
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
# 配置常規(guī)的友好錯誤提示頁
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}
}
nginx 里的 url 匹配,有一個特點,就是最先匹配原則,每一個請求,從上往下,先匹配到哪一個規(guī)則,就直接跳轉這個規(guī)則對應配置的 url
題外話
因為第三方的系統(tǒng),其實算是一個常規(guī)的系統(tǒng),比如,標配有登陸頁,我們需要吞掉登陸的這個步驟,所以,我們需要在動手腳的 x.min.js 里檢測第三方系統(tǒng)正確加載后,是否需要進行登陸操作,同時為了友好起見,我們需要添加一個遮罩層,在我們對第三方的頁面處理干凈之前,得先遮住不讓客戶看到。
等正確載入第三方的系統(tǒng)后,就可以按需要進行功能裁剪,樣式替換
到此這篇關于nginx 解決跨域問題嵌入第三方頁面的文章就介紹到這了,更多相關nginx 跨域嵌入第三方頁面內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!