web跨域

2022-08-05 12:18:07 字數 2080 閱讀 7534

之前對於跨域相關的知識一致都很零碎,正好現在的**中用到了跨域相關的,現在來對這些知識做一個彙總整理,方便自己檢視,說不定也可能對你有所幫助。

本篇主要內容如下:

相信很多人在 web 入門時,都被跨域問題折磨的死去活來。要想完全掌握跨域就得知道為什麼會有跨域這個問題出現。

簡單來說跨域問題是因為瀏覽器的同源策略導致的。那瀏覽器為什麼要有同源策略呢?

當然是為了安全。沒有同源策略限制的瀏覽器環境是非常危險的(即使有了同源策略也不是百分百安全),有興趣的可以去了解了解csrfxss攻擊。

所謂的“同源”指的是“三個相同”:

如果非同源頁面有以下限制:

但是這裡有個例外,所有帶“src”屬性的標籤都可以跨域載入資源,不受同源策略的限制,這樣你應該可以想到一個比較古老的跨域解決方案(jsonp),同時這個特性也會被用作 csrf 攻擊。

在前端開發中經常會遇到跨域的問題,比如前後端分離中前後端部署在不同的埠上,或者在前端頁面中需要向另外一個服務請求資料,這些都會被跨域所阻擋。

目前主要有以下幾種辦法解決跨域問題:

關閉瀏覽器同源檢查

這個太暴力,也太不安全了,不用考慮。

jsonp 實現跨域請求

前面說過了瀏覽器對於帶 src 屬性的標籤都可以跨域的。因此 jsonp 的實現流失利用了這個特性,在頁面中動態插入一個標籤,然後他的 src 屬性就是介面呼叫地址,這樣就能訪問過去了,然後再講返回內容特殊處理成立即執行的函式,這樣就看起像進行了一次跨域請求。之所以不推薦這種方式,主要有以下兩個原因:

伺服器設定執行跨域

這種方法只需要後臺做處理便能實現跨域,前面說的 http 跨域請求是能夠發出去的,只是不能接收,那我們只要在響應頭access-control-allow-headers中加入允許請求的地址即可,以,分隔,同時*代表所有地址都允許。比如:

access-control-allow-headers:http://localhost:8081,http://localhost:8082

本方法是較為常用的一中跨域辦法,只需簡單修改服務端**即可。

請求**

這也是非常常用的一種跨域方法。跨域限制只是瀏覽器限制,服務端並沒有這個概念,因此我們在前端還是請求同域地址,然後在服務端做一個**,將請求**到真正的 ip 和埠上。通常使用 nginx 實現埠**,比如下面一段 nginx 配置:

server 

# /test2/abc **到

location /test2/

# /test3/abc **到

location /test3/

}

cookie 的同源策略是通過

domainpath兩個部分來共同確認一個 cookie 在哪些頁面上可用。

domain確定這個 cookie 所屬的域名,不能帶埠或協議。因此 cookie 便可在不同埠/不同協議下共享,只要域名相同。有一個例外是父子域名間也能共享 cookie,只需將 domain 設定為.父域名

path就簡單多了,通過 domain 確定哪些域名可以共享 cookie,然後在通過path來確定 cookie 在哪些路徑下可用。使用/表示所有路徑都可共享。

具體如下:

注意:在跨域請求中,即時目標地址有 cookie 且發起請求的頁面也能讀取到該 cookie,瀏覽器也不會將 cookie 自動設定到該跨域請求中。比如在http://localhost:8082/a頁面中請求http://localhost:8081/abc,這兩個地址下擁有共享cookie,http請求也不會攜帶cookie。

gin框架開啟web跨域

前言 gin開啟跨域,只需要新增一個全域性中介軟體到路由器即可 gin的中介軟體可以新增到全域性, 也可以新增到單個路由上 新增到全域性 r...

MUI 跨域請求web api

由於剛接觸mui框架,所以在跨域問題上花了一點時間。希望我的方式能幫你少走點彎路 大神就直接過裡吧 ! 前端部分 1 mui js mui...

Web API中使用CORS解決跨域

如果兩個頁面的協議,埠和域名都相同,則兩個頁面具有相同的源,注 ie不考慮埠 同源策略不會阻止瀏覽器傳送請求,但是它會阻止應用程式看到響應。...