Nginx解決跨域問題

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

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

什么是跨域？

跨域就是跨域名，跨端口，跨協議（非同源策略）。

跨域分類

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

簡單跨域：不會發送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'``) {`` ``return` `204;`` ``}``}

上面的配置代碼即可解決跨域問題了，不想深入研究的，看到這里就可以了=-=

解釋

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 ‘http://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。即出現以下錯誤：

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

尾聲

解決跨域的解決方案有很多種，最常見也是最傳統的解決方式是使用JSONP的方式。CORS與JSONP的使用目的相同，但是比JSONP更強大。

JSONP只支持GET請求，CORS支持所有類型的HTTP請求。JSONP的優勢在于支持老式瀏覽器，以及可以向不支持CORS的網站請求數據。

HTTP Nginx

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。