1.為什麼會產生跨域問題
之所以會產生跨域問題是由於瀏覽器實現了同源策略(same origin policy),同源策略規定發起ajax請求時當原位址(原始域)和請求位址(請求域)的協議、網域名稱、埠號三者任意乙個不同就會引起跨域問題。
2.什麼是同源策略
最核心也最基本的安全功能,如果缺少了同源策略,則瀏覽器的正常功能可能都會受到影響。可以說web是構建在同源策略基礎之上的,瀏覽器只是針對同源策略的一種實現。
3.思考
也就是說跨域只會在瀏覽器端或者實現了同源策略的其他地方發生
4.跨域會有什麼後果(現象)
如果跨域了,也就是如果不滿足瀏覽器實現的同源協議,則會產生以下後果:
(1)無法讀取非同源網頁的 cookie、localstorage 和 indexeddb
(2)無法接觸非同源網頁的 dom
(3)無法向非同源位址傳送 ajax 請求
這就要從前後端互動的原理講起了。http請求是無狀態的,也就是說當我第一次訪問伺服器登入後,再傳送下乙個檢視個人資訊的請求,伺服器並不知道我之前已經登入過了(因為http協議是無狀態的),所以還是認為你沒有登入,這就衍生出了session和cookie。關於session和cookie的介紹可以參考
(1)瀏覽器傳送登入請求,第一次請求時伺服器會生成乙個session,可以將使用者的一些資訊儲存到session中。
(2)當請求返回時服務端呼叫set-cookie將sessionid存到cookie中並返回給瀏覽器儲存。
(3)瀏覽器帶著cookie請求個人資訊的介面,伺服器從cookie中取得sessionid,並根據這個id找到對應的session,檢視此使用者 的資訊是否和之前儲存的一致。
(4)伺服器返回個人資訊資料並將cookie也返回便於瀏覽器下次請求時帶著。
如果跨域了就是另一種狀態了
(1)瀏覽器傳送登入請求,第一次請求時伺服器會生成乙個session,可以將使用者的一些資訊儲存到session中。
(2)當請求返回時服務端呼叫set-cookie將sessionid存到cookie中並返回給瀏覽器儲存。但是由於跨域問題瀏覽器並不儲存這個cookie
(3)瀏覽器請求個人資訊的介面,但是帶不上cookie。伺服器生成乙個新的session,從session中找不到使用者資訊,此時又生成了乙個新的session,那麼兩次請求的sessionid必然不一致
(4)伺服器告訴瀏覽器我找不到你的登入資訊,瀏覽器端顯示為兩次請求的sessionid不一致,且明明登入了了服務端仍舊顯示 未登入。
思路:1.前端、後端、瀏覽器都允許跨域
2.前端、後端都允許帶有cookie
後端:自定義乙個過濾器,為httpservletresponse允許跨域且允許攜帶cookie
//允許來自所有域的訪問
response.setheader("access-control-allow-origin", "*");
//允許客戶端攜帶驗證資訊,例如 cookie 之類的
response.setheader("access-control-allow-credentials","true");
//響應標頭指定響應訪問所述資源到時允許的一種或多種方法預檢請求。
response.setheader("access-control-allow-methods", "get, post, options");
//允許瀏覽器header中帶有哪些字段
response.setheader("access-control-allow-headers",
"origin, no-cache, x-requested-with, if-modified-since, pragma, last-modified, cache-control, expires, content-type, x-e4m-with,authorization");
}前端:允許跨域且在跨域時強行攜帶cookie
export const axiosinstance = axios.create(` }
} else
}})()
},xhrfields:
// crossdomain: true
})
目前按道理說是應該解決跨域問題了,但是必須將後端的
response.setheader("access-control-allow-origin", "*");
這行**中的*改為瀏覽器具體ip,不能用*
這樣的話一對一除錯沒問題,但如果前端也是多人開發的話除錯依然不方便。此時我們要將瀏覽器也設為允許跨域才行
1.隨便建立乙個資料夾,比如我在地盤建了乙個mychromedata
2.賦值乙個chrome的快捷方式
注意:一定不要在原快捷方式上操作,因為使用設定了允許跨域後的瀏覽器瀏覽網頁時將受不到同源策略的保護,你訪問的帶有惡意**的頁面可以直接獲取甚至操作你同時訪問的帶有你敏感資訊(比如銀行、微博)。所以這個快捷方式設定好之後只用來開發測試就好了。
右鍵chrome快捷方式->屬性->目標,在原目標後面加上 --disable-web-security --user-data-dir=d:\mychromedata
注意最前邊有個空格
開啟瀏覽器顯示您使用的不是受支援的命令列標記: --disable-web-security則說明設定成功了。有時候瀏覽器會自動恢復預設設定,只需要再重新設定一次就可以了。
好了,終於可以愉快的開發了。
跨域問題詳解
access to xmlhttprequest at from origin has been blocked by cors policy no access control allow origin header is present on the requested resource.cor...
跨域問題詳解 ajax跨域解決
跨域問題的產出,根本原因在於瀏覽器的同源策略,什麼又是同源策略呢,官方解釋 同源策略限制了從同乙個源載入的文件或指令碼如何與來自另乙個源的資源進行互動。這是乙個用於隔離潛在惡意檔案的重要安全機制。同源的定義 如果兩個頁面的協議,埠 如果有指定 和網域名稱都相同,則兩個頁面具有相同的源。可以跨域讀取其...
請求跨域問題詳解
什麼是跨域 產生跨域的原因 以下三者都滿足 解決跨域的思路 解決跨域的方法 被調方過濾器解決方法 在過濾器中給預檢請求響應物件中增加對應頭部資訊告訴請求方這個請求允許跨域 res.addheader access control allow origin 允許跨域的請求源位址 res.addhead...