Django跨域資源共享問題(推薦)
最近做了一個前後端分離的web專案，其中我司職後端，使用django框架。在前後端整合測試的時候，就遇到了一些web安全相關的問題，cors跨域資源共享就是其中之一。
cors問題介紹
跨域資源共享(CORS) 是一種機制，它使用額外的 HTTP 頭來告訴瀏覽器 讓執行在一個 origin (domain) 上的Web應用被准許訪問來自不同源伺服器上的指定的資源。當一個資源從與該資源本身所在的伺服器不同的域、協議或埠請求一個資源時，資源會發起一個跨域 HTTP 請求。 CORS機制允許 Web 應用伺服器進行跨域訪問控制，從而使跨域資料傳輸得以安全進行。現代瀏覽器支援在API容器中使用CORS，以降低跨域 HTTP 請求所帶來的風險。
一個域是由協議、主機和埠號組成的，簡單地說，當兩個url的協議、主機和埠中存在一個不同時，它們屬於不同域，那麼它們之間的互相訪問就會產生跨域訪問問題。
我的專案中，前端的地址是http://localhost:8001,後端的地址是http://localhost:8000,兩個地址的協議和主機都相同，但是埠號不同，因此，前端呼叫後端介面時，就會產生跨域訪問的問題。
簡單請求
簡單請求不會觸發跨域訪問中的預檢請求，滿足下列條件的為簡單請求:
使用下列方法之一
GET
HEAD
POST
headers欄位集合主要包含以下型別：
- Accept
- Accept-Language
- Content-Language
- Content-type :text/plain 、multipart/form-data 和application/x-www-form-urlencoded
- DRP
- DownLink
- Save-Data
- Viewport-Width
- Width
非簡單請求
非簡單請求即不滿足簡單請求條件的請求。非簡單請求在發出請求前需要先發送一個預檢請求，請求方法為OPTIONS 方法。預檢請求的使用，可以避免跨域請求對伺服器的使用者資料產生未預期的影響。 當請求滿足下述任一條件時，即應首先發送預檢請求：
使用了以下的HTTP方法:
PUT
DELETE
CONNECT
OPTIONSTRACE
PATCH
首部欄位裡面包含了非簡單請求的頭部欄位的欄位
django中遇到的問題
在後臺開發中，就遇到了這樣的情況
錯誤提示中顯示，請求被CORS 協議阻攔。
這裡的Origin 欄位說明了請求源地址，採用了OPTIONS 方法，然後發出請求的地址Host
就是本機地址。下面是伺服器的響應，但是沒有發出實際請求
然後，為了解決這一問題，我搜索過後，安裝了django-cors-headers庫，並且進行了配置，這裡配置時我把django-cors-headers中介軟體放在了中介軟體第一位。再次訪問同樣的地址，結果如下：
1.首先，瀏覽器檢測訪問的請求頭中的欄位，存在對CORS 安全的首部欄位集合之外的欄位，所以，向伺服器傳送一個預檢請求。上圖可見，方法為OPTIONS ，該方法不會對伺服器資源產生影響。其中的請求頭中的Access-Control-Request-Method 欄位表明實際請求會採用 GET 方法，Origin 表示請求源，會在伺服器中接受驗證。
2.驗證通過後，會在response 請求頭新增不同的欄位進行返回， 欄位的意思如下：
- 首部欄位Access-Control-Allow-Headers ：表示伺服器允許的頭部欄位。
- 首部欄位Access-Control-Allow-Methods ：表明伺服器允許客戶端使用POST,GET 和OPTIONS 等等方法發起請求。
- 首部欄位Access-Control-Allow-Origin ：表示伺服器允許的請求源。
- 首部欄位Access-Control-Max-Age :表明該響應的有效時間為86400秒，也就是24 小時。在有效時間內，瀏覽器無須為同一請求再次發起預檢請求。
3.然後，客戶端會發出實際請求，從結果上來看，預檢請求的response 請求體中沒有任何資訊，而實際請求則攜帶了伺服器返回的資訊。不難看出，預檢請求確實就是與伺服器提前溝通，獲取與伺服器相關資訊的。
簡單的總結
非簡單請求需要傳送預檢請求進行判斷，然後服務端與客戶端需要在頭部欄位上達成一致，這樣才能正常訪問。不過，在django的開發中，直接使用django-cors-headers庫以後，只需要簡單的配置就能夠很好的解決問題。
到此這篇關於Django跨域資源共享問題小結的文章就介紹到這了,更多相關django跨域資源共享內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！