資訊專欄INFORMATION COLUMN
摘要：通過將屬性設(shè)置為，可以指定某個(gè)請求應(yīng)該發(fā)送憑據(jù)。前臺跨域請求，由于規(guī)范的存在，瀏覽器會首先發(fā)送一次嗅探，同時(shí)帶上，判斷是否有跨域請求權(quán)限，服務(wù)器響應(yīng)的值，供瀏覽器與匹配，如果匹配則正式發(fā)送請求。
話不多說，一個(gè)字，干！
前端配置如下：
axios.defaults.withCredentials = true; //配置為true
axios.post("http://localhost:3000/tpzdz/vote/all", {
openid: "oJ0mVw4QrfS603gFa_uAFDADH2Uc",
date: "2018-11-21"
}).then(function (response) {
console.log(response)
})
前端配置withCredentials = true 后端的跨域也需要配置
app.use(async (ctx, next) => {
ctx.set("Access-Control-Allow-Origin", ctx.request.header.origin);
ctx.set("Access-Control-Allow-Credentials", true);
await next();
});
//防止每次請求都返回Access-Control-Allow-Methods以及Access-Control-Max-Age，
//這兩個(gè)響應(yīng)頭其實(shí)是沒有必要每次都返回的，只是第一次有預(yù)檢的時(shí)候返回就可以了。
app.use(async (ctx, next) => {
if (ctx.method === "OPTIONS") {
ctx.set("Access-Control-Allow-Methods", "PUT,DELETE,POST,GET");
ctx.set("Access-Control-Max-Age", 3600 * 24);
ctx.body = "";
}
await next();
});
實(shí)例展示完了，我們來講講都是怎么回事
withCredentials:默認(rèn)情況下，跨源請求不提供憑據(jù)(cookie、HTTP認(rèn)證及客戶端SSL證明等)。通過將withCredentials屬性設(shè)置為true，可以指定某個(gè)請求應(yīng)該發(fā)送憑據(jù)。
默認(rèn)值為false。
true：在跨域請求時(shí)，會攜帶用戶憑證
false：在跨域請求時(shí)，不會攜帶用戶憑證；返回的 response 里也會忽略 cookie
當(dāng)配置了 withCredentials = true時(shí)，必須在后端增加 response 頭信息Access-Control-Allow-Origin，且必須指定域名，而不能指定為*！??！
那么問題就來了，若是多個(gè)域名呢？
我配置的是任意域名都可以訪問，但是這樣并不安全。建議做法是創(chuàng)建一個(gè)數(shù)組，每次去檢測域名是否在數(shù)組內(nèi)，存在則繼續(xù)
講到這里了，那么延伸一下 post請求下的options
options 它是一種探測性的請求，通過這個(gè)方法，客戶端可以在采取具體資源請求之前，決定對該資源采取何種必要措施，或者了解服務(wù)器的性能。
前臺跨域post請求，由于CORS（cross origin resource share）規(guī)范的存在，瀏覽器會首先發(fā)送一次options嗅探，同時(shí)header帶上origin，判斷是否有跨域請求權(quán)限，服務(wù)器響應(yīng)access control allow origin的值，供瀏覽器與origin匹配，如果匹配則正式發(fā)送post請求。
每一次非簡單請求都會實(shí)際上發(fā)出兩次請求，一次預(yù)檢一次真正請求，這就比較損失性能了。
所以就有了2圖的中間件。 Access-Control-Max-Age: 86400
設(shè)置一個(gè)相對時(shí)間，在該非簡單請求在服務(wù)器端通過檢驗(yàn)的那一刻起，當(dāng)流逝的時(shí)間的毫秒數(shù)不足Access-Control-Max-Age時(shí)，就不需要再進(jìn)行預(yù)檢，可以直接發(fā)送一次請求。
但是為什么會有兩個(gè)中間件的設(shè)置呢，推薦文章 https://www.jb51.net/article/... 很細(xì)致哦
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/100454.html
這個(gè)百度貼吧的項(xiàng)目是 vue + koa + sequelize 的項(xiàng)目。 由于沒有百度貼吧API接口，所以自己寫了后端 項(xiàng)目部分截圖（GIF） showImg(https://user-gold-cdn.xitu.io/2019/7/13/16bea513a0805b84?w=480&h=1040&f=gif&s=4456077);showImg(https://user-gold-cdn.xi...
摘要：查找原因無法獲取到是因?yàn)橥床呗院蜆?biāo)記的原因。在同一個(gè)站點(diǎn)下使用屬性是無效的。此外，這個(gè)指示也會被用做響應(yīng)中被忽視的標(biāo)示。而通過設(shè)置為獲得的第三方，將會依舊享受同源策略，因此不能被通過或者從頭部相應(yīng)請求的腳本等訪問。 作者：codexu _ showImg(https://segmentfault.com/img/remote/1460000020161476); 瀏覽器里明明存在的c...
摘要：同源策略禁止使用對象向不同源的服務(wù)器地址發(fā)起請求。借助于決解同源策略決解同源策略，新方案跨域資源共享這里講的重點(diǎn)跨域資源共享提供的標(biāo)準(zhǔn)跨域解決方案，是一個(gè)由瀏覽器共同遵循的一套控制策略，通過的來進(jìn)行交互主要通過后端來設(shè)置配置項(xiàng)。 了解下同源策略 源（origin）*：就是協(xié)議、域名和端口號； 同源： 就是源相同，即協(xié)議、域名和端口完全相同； 同源策略：同源策略是瀏覽器的一個(gè)安全...
閱讀 2077·2023-04-25 19:15
閱讀 2245·2021-11-23 09:51
閱讀 1264·2021-11-17 09:33
閱讀 2165·2021-08-26 14:15
閱讀 2476·2019-08-30 15:54
閱讀 1582·2019-08-30 15:54
閱讀 2167·2019-08-30 12:50
閱讀 1132·2019-08-29 17:08
