最近做了乙個前後端分離的web專案，其中我司職後端，使用django框架。在前後端整合測試的時候，就遇到了一些web安全相關的問題，cors跨域資源共享就是其中之一。
cors問題介紹
跨域資源共享(cors) 是一種機制，它使用額外的 http 頭來告訴瀏覽器 讓執行在乙個 origin (domain) 上的web應用被准許訪問來自不同源伺服器上的指定的資源。當乙個資源從與該資源本身所在的伺服器不同的域、協議或埠請求乙個資源時，資源會發起乙個跨域 http 請求。 cors機制允許 web 應用伺服器進行跨域訪問控制，從而使跨域資料傳輸得以安全進行。現代瀏覽器支援在api容器中使用cors，以降低跨域 http 請求所帶來的風險。
乙個域是由協議、主機和埠號組成的，簡單地說，當兩個url的協議、主機和埠中存在乙個不同時，它們屬於不同域，那麼它們之間的互相訪問就會產生跨域訪問問題。
我的專案中，前端的位址是 http://localhost:8001 ,後端的位址是 http://localhost:8000 ,兩個位址的協議和主機都相同，但是埠號不同，因此，前端呼叫後端介面時，就會產生跨域訪問的問題。
簡單請求
簡單請求不會觸發跨域訪問中的預檢請求，滿足下列條件的為簡單請求:
使用下列方法之一
gethead
post
headers欄位集合主要包含以下型別：
非簡單請求
非簡單請求即不滿足簡單請求程式設計客棧條件的請求。非簡單請求在發出請求前需要先傳送乙個預檢請求，請求方法為 option程式設計客棧s 方法。預檢請求的使用，可以避免跨域請求對伺服器的使用者資料產生未預期的程式設計客棧影響。 當請求滿足下述任一條件時，即應首先傳送預檢請求：
使用了以下的http方法:
putdelete
connect
options
trace
patch
首部字段裡面包含了非簡單請求的頭部欄位的字段
django中遇到的問題
在後台開發中，就遇到了這樣的情況
錯誤提示中顯示，請求被 cors 協議阻攔。
這裡的 origin 字段說明了請求源位址，採用了 options 方法，然後發出請求的位址 host
就是本機位址。下面是伺服器的響應，但是沒有發出實際請求
然後，為了解決這一問題，我搜尋過後，安裝了django-cors-headers庫，並且進行了配置，這裡配置時我把django-cors-headers中介軟體放在了中介軟體第一位。再次訪問同樣的位址，結果如下：
1.首先，瀏覽器檢測訪問的請求頭中的字段，存在對 cors 安全的首部字段集合之外的字段，所以，向伺服器傳送乙個預檢請求。上圖可見，方法為 options ，該方法不會對伺服器資源產生影響。其中的請求頭中的 access-control-request-method 字段表明實際請求會採用 get 方法， origin 表示請求源，會在伺服器中接受驗證。
2.驗證通過後，會在 response 請求頭新增不同的字段進行返回， 欄位的意思如下：
3.然後，客戶端會發出實際請求，從結果上來看，預檢請求的 response 請求體中沒有任何資訊，而實際請求則攜帶了伺服器返回的資訊。不難看出，預檢請求確實就是與伺服器提前溝通，獲取與伺服器相關資訊的。
簡單的總結
非簡單請求需要傳送預檢請求進行判斷，然後服務端與客戶端需要在頭部欄位上達成一致，這樣才能正常訪問。不過，在django的開發中，直接使用django-cors-headers庫以後，只需要簡單的配置就能夠很好的解決問題。
跨域資源共享
跨域資源共享 跨域資源共享。新增了一組http首部字段，允許伺服器宣告哪些源站有許可權訪問哪些資源，瀏覽器首先使用otions方法發起乙個預檢請求，從而獲知服務端是否允許該跨域請求，服務端確認允許後，才發起實際的http請求，在預檢請求的返回中，伺服器端也可以通知客戶端，是否需要攜帶身份憑證 滿足下...
跨域資源共享 CORS
cors需要瀏覽器和伺服器同時支援。目前，所有瀏覽器都支援該功能。前端 對應於前端請求來說cors通訊與同源的ajax通訊沒有差別，完全一樣。瀏覽器一旦發現ajax請求跨源，就會自動新增一些附加的頭資訊，有時還會多出一次附加的請求，但使用者不會有感覺。後端 只要伺服器實現了cors介面，就可以跨源通...
跨域資源共享 CORS
跨域資源共享 cross origin resource sharing 是一種機制，它使用額外的 http 頭部告訴瀏覽器可以讓乙個web應用進行跨域資源請求。若乙個請求同時滿足下述所有條件，則該請求可視為 簡單請求 注 灰色字型內容了解即可 手動設定的頭部字段只能是 注意 也可以設定 forbi...