先來說說目前前後端分離後，前端和後端是怎麼進行數據交互的。在《MiniMall：說一說前端代碼框架，你愛看不看》文章中，我們介紹前端採用的是Extjs框架實現，然後通過Nginx進行代理轉發。下來看看現在的Nginx代理配置：
server {
listen 80;
server_name api.mall.com;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $host;
location / {
proxy_pass http://127.0.0.1:9015; #將請求轉發到網關
proxy_connect_timeout 600;
proxy_read_timeout 600;
}
}
server {
listen 80;
server_name manage.mall.com;
#配置跨域
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Headers X-Requested-With;
add_header Access-Control-Allow-Methods GET,POST,OPTIONS;
location / {
root F:/workspace/mini-mall-web; # 前端工程的根路徑
autoindex on;
}
}
- api.mall.com：代理的是網關服務地址，所有的請求會先經過網關，然後由網關進行路由到各個微服務中。
- manage.mall.com：代理的是前端工程的根路徑，通過
http://manage.mall.com訪問前端界面。
很明顯，前端和服務端是處於兩個不同的域裏，那勢必會引起跨域問題。
1. 跨域問題
跨域是瀏覽器對於javascript的同源策略的一種限制。以下情況都屬於跨域：
| 跨域原因說明 | 示例 |
|---|---|
| 域名不同 | www.jd.com 與 www.taobao.com |
| 域名相同，端口不同 | www.jd.com:8080 與 www.jd.com:8081 |
| 二級域名不同 | item.jd.com 與 miaosha.jd.com |
如果域名和端口都相同，但是請求路徑不同，不屬於跨域，如：www.jd.com/item 和www.jd.com/goods。其中http和https也屬於跨域，而我們剛纔是從manage.mall.com去訪問api.mall.com，這屬於二級域名不同，跨域了。
2. 爲什麼有跨域問題
跨域不一定都會有跨域問題。因爲跨域問題是瀏覽器對於ajax請求的一種安全限制：一個頁面發起的ajax請求，只能是與當前頁域名相同的路徑，這能有效的阻止跨站攻擊。因此：跨域問題 是針對ajax的一種限制。
但是這卻給我們的開發帶來了不便，而且在實際生產環境中，肯定會有很多臺服務器之間交互，地址和端口都可能不同，怎麼辦？
3. 解決跨域問題的方案
目前比較常用的跨域解決方案有3種：
-
Jsonp
最早的解決方案，利用script標籤可以跨域的原理實現。限制：
- 需要服務的支持
- 只能發起GET請求
-
nginx反向代理
思路是：利用nginx把跨域反向代理爲不跨域，支持各種請求方式。
缺點：需要在nginx進行額外配置，語義不清晰。
-
CORS
規範化的跨域請求解決方案，安全可靠。
優勢：
- 在服務端進行控制是否允許跨域，可自定義規則。
- 支持各種請求方式。
缺點：
- 會產生額外的請求。
我們這裏會採用cors的跨域方案。
4. cors解決跨域
4.1.什麼是cors
CORS是一個W3C標準，全稱是"跨域資源共享"（Cross-origin resource sharing）。
它允許瀏覽器向跨源服務器，發出XMLHttpRequest請求，從而克服了AJAX只能同源使用的限制。
CORS需要瀏覽器和服務器同時支持。目前，所有瀏覽器都支持該功能，IE瀏覽器不能低於IE10。
-
瀏覽器端：
目前，所有瀏覽器都支持該功能（IE10以下不行）。整個CORS通信過程，都是瀏覽器自動完成，不需要用戶參與。
-
服務端：
CORS通信與AJAX沒有任何差別，因此你不需要改變以前的業務邏輯。只不過，瀏覽器會在請求中攜帶一些頭信息，我們需要以此判斷是否允許其跨域，然後在響應頭中加入一些信息即可。這一般通過過濾器完成即可。
4.2 原理有點複雜
瀏覽器會將ajax請求分爲兩類，其處理方案略有差異：簡單請求、特殊請求。
只要同時滿足以下兩大條件，就屬於簡單請求。：
（1）請求方法是以下三種方法之一：
- HEAD
- GET
- POST
（2）HTTP的頭信息不超出以下幾種字段：
- Accept
- Accept-Language
- Content-Language
- Last-Event-ID
- Content-Type：只限於三個值
application/x-www-form-urlencoded、multipart/form-data、text/plain
當瀏覽器發現發起的ajax請求是簡單請求時，會在請求頭中攜帶一個字段：Origin。
Origin中會指出當前請求屬於哪個域（協議+域名+端口），服務會根據這個值決定是否允許其跨域。如果服務器允許跨域，需要在返回的響應頭中攜帶下面信息：
Access-Control-Allow-Origin: http://manage.mall.com
Access-Control-Allow-Credentials: true
Content-Type: text/html; charset=utf-8
- Access-Control-Allow-Origin：可接受的域，是一個具體域名或者*（代表任意域名）
- Access-Control-Allow-Credentials：是否允許攜帶cookie，默認情況下，cors不會攜帶cookie，除非這個值是true
要想操作cookie，需要滿足3個條件：
- 服務的響應頭中需要攜帶Access-Control-Allow-Credentials並且爲true。
- 瀏覽器發起ajax需要指定withCredentials 爲true。
- 響應頭中的Access-Control-Allow-Origin一定不能爲*，必須是指定的域名。
4.3 特殊請求
不符合簡單請求的條件，會被瀏覽器判定爲特殊請求，例如請求方式爲PUT。
預檢請求
特殊請求會在正式通信之前，增加一次HTTP查詢請求，稱爲"預檢"請求（preflight）。
瀏覽器先詢問服務器，當前網頁所在的域名是否在服務器的許可名單之中，以及可以使用哪些HTTP動詞和頭信息字段。只有得到肯定答覆，瀏覽器纔會發出正式的XMLHttpRequest請求，否則就報錯。
一個“預檢”請求的樣板：
OPTIONS /cors HTTP/1.1
Origin: http://manage.mall.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.leyou.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...
與簡單請求相比，除了Origin以外，多了兩個頭：
- Access-Control-Request-Method：接下來會用到的請求方式，比如PUT。
- Access-Control-Request-Headers：會額外用到的頭信息。
預檢請求的響應
服務的收到預檢請求，如果許可跨域，會發出響應：
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://manage.mall.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Max-Age: 1728000
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
除了Access-Control-Allow-Origin和Access-Control-Allow-Credentials以外，這裏又額外多出3個頭：
- Access-Control-Allow-Methods：允許訪問的方式
- Access-Control-Allow-Headers：允許攜帶的頭
- Access-Control-Max-Age：本次許可的有效時長，單位是秒，過期之前的ajax請求就無需再次進行預檢了
如果瀏覽器得到上述響應，則認定爲可以跨域，後續就跟簡單請求的處理是一樣的了。
4.4 實現非常簡單
雖然原理比較複雜，但是前面說過：
- 瀏覽器端都有瀏覽器自動完成，我們無需操心。
- 服務端可以通過攔截器統一實現，不必每次都去進行跨域判定的編寫。
事實上，SpringMVC已經幫我們寫好了CORS的跨域過濾器：CorsFilter,內部已經實現了剛纔所講的判定邏輯，我們直接用就好了。在mall-gateway-server中編寫一個配置類，並且註冊CorsFilter：
@Configuration
public class CorsConfig {
@Bean
public CorsFilter corsFilter() {
//1.添加CORS配置信息
CorsConfiguration config = new CorsConfiguration();
//1) 允許的域,不要寫*，否則cookie就無法使用了
config.addAllowedOrigin("http://manage.mall.com");
//2) 是否發送Cookie信息
config.setAllowCredentials(true);
//3) 允許的請求方式
config.addAllowedMethod("OPTIONS");
config.addAllowedMethod("HEAD");
config.addAllowedMethod("GET");
config.addAllowedMethod("PUT");
config.addAllowedMethod("POST");
config.addAllowedMethod("DELETE");
config.addAllowedMethod("PATCH");
//4）允許的頭信息
config.addAllowedHeader("*");
//2.添加映射路徑，我們攔截一切請求
UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
configSource.registerCorsConfiguration("/**", config);
//3.返回新的CorsFilter.
return new CorsFilter(configSource);
}
}
大功告成，完美解決跨域問題。說了一大堆，實際代碼只有一個CorsConfig類。
