HTTP之訪問控制「CORS」

序言

跨域資源共享「CORS」就是在不一樣的域名、協議、端口直接請求資源。本文主要講述了什麼是跨域，什麼狀況下會出現預檢請求，我司的跨域安全訪問

什麼是跨域

同源策略

出於安全的緣由，在沒有被容許的狀況下瀏覽器限制從不一樣源「origin」發起請求，也多是跨站請求能夠正常發起，可是返回結果被瀏覽器攔截了。

什麼才能是同源

源：由協議+域名+端口組成，也就是說，這個三個要統一才同源

例：

• http://www.baidu.com && https://www.baidu.com 不一樣源 協議不一樣
• http://api.baidu.com && http://www.baidu.com 不一樣源 域名不一樣
• http://www.baidu.com:8081 && http://www.baidu.com:8080 不一樣源 端口不一樣
• www.baidu.com/index.html && www.baidu.com/404.html 同源

什麼狀況下會出現預檢請求

預檢請求

跨域資源共享標準新增了一組HTTP首部字段，容許服務器聲明哪些源站經過瀏覽器有權限訪問哪些資源。在某些會對服務器數據產生做用「須要修改數據庫」的請求「主要是GET之外的請求」，瀏覽器會先發送經過OPTIONS方法發送預檢請求，從服務器那邊獲得返回是否容許跨域。服務器也能夠攜帶是否須要身份憑證通知瀏覽器。

也就是說：在你發送請求的時候，瀏覽器會本身先發送一個預檢請求。後臺只須要識別請求的方法「OPTIONS」，而後返回一些信息。 以下圖：

這裏有兩個login/請求，第一個是瀏覽器主動發出的。它的Request Method方法爲 OPTIONS，而後服務器的返回信息：

• access-control-allow-headers：容許你攜帶頭的參數
• access-control-allow-methods：容許你發送請求的方法
• access-control-allow-origin：容許你發送請求的地址

這部分信息通知了你修改本身的請求參數來符合服務器的要求， 服務器如何除了瀏覽器發送的預檢請求，能夠參照這個MDN Server-Side_Access_Control (CORS)。

簡單請求

在如下狀況下發送的請求不會觸發預檢請求

• 使用如下方法之一：「GET HEAD POST」

• 頭部字段在這個集合以內：「Accept， Accept-Language， Content-Language， Content-Type （須要注意額外的限制）， DPR， Downlink， Save-Data， Viewport-Width， Width」

• Content-Type如下三種之一：「text/plain，multipart/form-data，application/x-www-form-urlencoded」

• ...

例子：我在發送登陸的時候，頭部字段自定義了Authorization，這時候就觸發預檢請求

我司的訪問控制方式

JSON Web Token「JWT」

公司主要採用的就是JWT的跨域認證解決方案。JWT的意思就是：用戶發送登陸信息「用戶名，密碼」給服務器，服務器認證後生成一個JSON對象，給用戶儲存，以後用戶請求數據都須要帶上JWT來發送請求。

步驟

• 1. 登陸 發送用戶名密碼給服務器驗證返回JWT

• 2. 前端經過LocalStorage儲存JWT

• 3. 以後的請求帶上JWT

     

• 4. 驗證過時或者失敗直接返回401退到登陸頁面

     

不足之處

• JWT一旦簽發了，在到期以前始終有效，這樣別人可使用你的JWT獲取數據
• JWT過時或失效的時候，用戶仍然須要經過失效的JWT請求才能知道JWT已經失效

擴展閱讀

若是前端沒有跟後端創建統一API設計規範，可使用這個 RESTful api

參考

MDN HTTP訪問控制 阮一峯 JWT入門教程