如何使用Nginx解決跨域問題詳解

2022-05-13 21:51:56

先來說一下什麼是同源策略

同源(域名、協定、埠相同)策略是一種約定，是瀏覽器最核心也是最基本的安全功能，如果缺少了同源策略，瀏覽器的正常功能將受到影響。

什麼是跨域？

跨域就是跨域名，跨埠，跨協定（非同源策略）。

跨域分類

簡單說，跨域分為 簡單跨域 和 複雜跨域。

簡單跨域：不會傳送OPTIONS請求。

複雜跨域：會傳送一個預檢查OPTIONS請求。

複雜跨域的條件是：

①、非GET、HEAD、POST請求。

②、POST請求的Content-Type不是application/x-www-form-urlencoded, multipart/form-data, 或text/plain。

③、新增了自定義header，例如Token。

跨域請求瀏覽器會在Headers中新增Origin，通常情況下不允許使用者修改其值。

Nginx解決跨域問題

跨域是前後端分離開發中非常常見的問題。無論用什麼程式語言，現在都已經很難離開Nginx。因此直接在Nginx中處理跨域問題有得天獨厚的優勢。當出現跨域問題的時候，只需要給Nginx伺服器設定響應的header引數即可。

只需要在Nginx的組態檔中設定以下引數：

location /
{
     add_header Access-Control-Allow-Origin *;
     add_header 'Access-Control-Allow-Credentials''true'; # 是否允許後續請求攜帶cookies,該值只能是true,否則不返回。如果上面的Access-Control-Allow-Origin設定的是* 而你又需要cookie資訊,則 必須設定這行。  add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS';  add_header Access-Control-Allow-Headers *; if($request_method = 'OPTIONS')
    {
         return204; 
    }
}

上面的設定程式碼即可解決跨域問題了，不想深入研究的，看到這裡就可以了=-=

解釋

1、Access-Control-Allow-Origin

伺服器預設是不被允許跨域的。給Nginx設定Access-Control-Allow-Origin * 後，表示伺服器可以接受所有的請求源（Origin）,即接受所有跨域的請求。也就是說，表示接受任意域名的請求。上面我們這裡設定的是* 這是最簡單粗暴的方式，但是伺服器出於安全考慮，肯定不會這麼幹，而且，如果是*的話，遊覽器將不會傳送cookies資料（如果需要攜帶cookies資料，則需要設定 'Access-Control-Allow-Credentials:true'）。

所以Access-Control-Allow-Origin一般都是設定為指定域（也就是指定某一個url來請求我伺服器）的方式。指定域設定的方式如下：

add_header Access-Control-Allow-Origin 'www.test.com'; 注意：只能指定一個域

2、Access-Control-Allow-Headers 是為了防止出現以下錯誤：

Request header field Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

這個錯誤表示當前請求Content-Type的值不被支援。其實是我們發起了"application/json"的型別請求導致的。這裡涉及到一個概念：預檢請求（preflight request）。請看下面"預檢請求"的介紹。

3、Access-Control-Allow-Methods 是為了防止出現以下錯誤：

Content-Type is not allowed by Access-Control-Allow-Headers in preflight response.

4、給OPTIONS 新增 204的返回，是為了處理在傳送POST請求時Nginx依然拒絕存取的錯誤

傳送"預檢請求"時，需要用到方法OPTIONS,所以伺服器需要允許該方法。

預檢請求（preflight request）

其實上面的設定涉及到了一個W3C標準：CROS，全稱是跨域資源共用 (Cross-origin resource sharing)，它的提出就是為了解決跨域請求的。

跨域資源共用（CORS）標準新增了一組HTTP 首部欄位，允許伺服器宣告哪些源站有許可權存取哪些資源。另外，規範要求，對那些可能對伺服器資料產生副作用的HTTP 請求方法（特別是 GET 以外的 HTTP 請求，或者搭配某些 MIME 型別的 POST 請求），瀏覽器必須首先使用 OPTIONS 方法發起一個預檢請求（preflight request），從而獲知伺服器端是否允許該跨域請求。伺服器確認允許之後，才發起實際的 HTTP 請求。在預檢請求的返回中，伺服器端也可以通知使用者端，是否需要攜帶身份憑證（包括 Cookies 和 HTTP 認證相關資料）。

其實Content-Type欄位的型別為application/json的請求就是上面所說的搭配某些 MIME 型別的 POST 請求，CORS規定，Content-Type不屬於以下MIME型別的，都屬於預檢請求：

application``/x-www-form-urlencoded``multipart``/form-data``text``/plain

POST請求中的Content-Type不是上面這三種的其中一種的話，都屬於預檢請求。（上面也有提到過，就是複雜跨域的條件中的第②步）

所以 application/json的請求會在正式通訊之前，增加一次"預檢"請求，這次"預檢"請求會帶上頭部資訊 Access-Control-Request-Headers: Content-Type：

OPTIONS /api/test HTTP/1.1``Origin: http://foo.example``Access-Control-Request-Method: POST``Access-Control-Request-Headers: Content-Type``... 省略了一些

伺服器迴應時，返回的頭部資訊如果不包含Access-Control-Allow-Headers: Content-Type則表示不接受非預設的的Content-Type。

即出現以下錯誤：