同源策略

理解跨域首先必須要了解同源策略。同源策略是瀏覽器上為安全性考慮實施的非常重要的安全策略。何謂同源：URL由協議、域名、端口和路徑組成，如果兩個URL的協議、域名和端口相同，則表示他們同源。

跨域就是通過某些手段來繞過同源策略限制，實現不同服務器之間通信的效果。具體策略限制情況可看下表：

只有文件協議、域名、端口和路徑全部相同，這些文件才會是同源，同源文件間請求無須特殊處理，當不同源文件之間發生請求時，則需要跨域處理。

jsonp實現跨域原理

什么是jsonp？
參考百度百科，JSONP(JSON with Padding)是JSON的一種“使用模式”，可用于解決主流瀏覽器的跨域數據訪問的問題。由于同源策略，一般來說位于 server1.example.com 的網頁無法與不是 server1.example.com的服務器溝通，而 HTML 的<script> 元素是一個例外。利用 <script> 元素的這個開放策略，網頁可以得到從其他來源動態產生的 json資料，而這種使用模式就是所謂的 jsonp。用 jsonp抓到的資料并不是 json，而是任意的JavaScript，用 JavaScript 直譯器執行而不是用 json解析器解析。

jsonp原理：
首先在客戶端注冊一個callback, 然后把callback的名字傳給服務器。此時，服務器先生成 json 數據。然后以 javascript 語法的方式，生成一個function , function 名字就是傳遞上來的參數 jsonp 。最后將 json 數據直接以入參的方式，放置到 function 中，這樣就生成了一段 js 語法的文檔，返回給客戶端。客戶端瀏覽器，解析script標簽，并執行返回的 javascript 文檔，此時數據作為參數，傳入到了客戶端預先定義好的 callback 函數里.（動態執行回調函數）

jsonp作用：
由于同源策略的限制，XmlHttpRequest只允許請求當前源（域名、協議、端口）的資源，為了實現跨域請求，可以通過script標簽實現跨域請求，然后在服務端輸出json數據并執行回調函數，從而解決了跨域的數據請求。

jsonp缺點：

1. 它只支持GET請求而不支持POST等其它類型的HTTP請求（雖然采用post+動態生成iframe是可以達到post跨域的目的，但這樣做是一個比較極端的方式，不建議采用）。
2. jsonp易于實現，但是也會存在一些安全隱患，如果第三方的腳本隨意地執行，那么它就可以篡改頁面內容，截獲敏感數據。但是在受信任的雙方傳遞數據，jsonp是非常合適的選擇。可以看出來jsonp跨域一般用于獲取其他域的數據。

一言不合上代碼

獲取json數據

使用jsonp獲取json數據，類似同源post請求獲取json數據，不過jsonp只支持get請求。

1. 客戶端注冊callback，并將callback名字傳給服務器

$.ajax({ url: "http://localhost:8080" + "/my/order/cancel?orderNo=" + orderNo,    
 type: "get",        
 dataType: "jsonp",    
 jsonp: 'callback',   
 jsonpCallback: 'jsonp_callback',    
 success: function (data, status) {   
    //回調處理  
    alert（data）;   
   }
});

上述代碼，callback是回傳至服務器參數，服務器使用callback參數拼接服務器端請求結果（json數據），返回給客戶端。

*2. 服務器端處理請求 *

  @RequestMapping("/cancel")
  @ResponseBodypublic JSONPObject cancelOrder(String orderNo, HttpSession session, HttpServletRequest request, HttpServletResponse response, String callback) {   
   // 獲取用戶信息    
  Member member = (Member)   session.getAttribute(Constants.SESSION_MEMBER_NAME);   
  String operateIp = ClientIpUtil.getClientIp(request);    
  UserOrderOpCtx operateCtx = new UserOrderOpCtx(orderNo,String.valueOf(member.getId()),member.getNickName(),operateIp);   
   userOrderApiService.cancelOrder(operateCtx);
   response.setContentType("text/plain");    
   return new JSONPObject(callback, MapUtils.getMap(RespEnum.OK, "訂單取消成功!"));   
}

根據請求客戶端請求參數callback，組裝jsonp數據，返回給客戶端；

獲取html數據

有些業務場景需要跨域獲取其他系統頁面數據，類似同源間get請求；
1. 客戶端注冊callback，并將callback名字傳給服務器

$.ajax({ url: "http://localhost:8080" + "/my/order/cancel?orderNo=" + orderNo,    
 type: "get",        
 dataType: "jsonp",    
 jsonp: 'callback',   
 jsonpCallback: 'jsonp_callback',    
 success: function (data, status) {   
    //回調處理  
    alert（data）;   
   }
});

上述代碼，callback是回傳至服務器參數，服務器使用callback參數拼接服務器端請求結果（json數據），返回給客戶端。
*2. 服務器端處理請求 *

  @RequestMapping("/cancel")
  public void cancelOrder(String orderNo, HttpSession session,HttpServletResponse response, String callback) {   
   // 獲取用戶信息    
  Member member = (Member)   session.getAttribute(Constants.SESSION_MEMBER_NAME);   
  String operateIp = ClientIpUtil.getClientIp(request);    
  UserOrderOpCtx operateCtx = new     UserOrderOpCtx(orderNo,String.valueOf(member.getId()),member.getNickName(),operateIp);   
  userOrderApiService.cancelOrder(operateCtx);
  response.setContentType("text/plain");    
  response.getWriter().write(callback+ "JSON.toJSON(MapUtils.getMap(RespEnum.OK, "訂單取消成功!"))"); //返回jsonp數據
}

HTTP訪問控制

跨源資源共享(CROS)讓Web應用服務器能支持跨站訪問控制，從而使得安全地進行跨站數據傳輸成為可能。需要特別注意的是，這個規范是針對API容器的。比如說，要使得XMLHttpRequest在現代瀏覽器中可以發起跨域請求。瀏覽器必須能支持跨源共享帶來的新的組件，包括請求頭和策略執行。同樣，服務器端則需要解析這些新的請求頭，并按照策略返回相應的響應頭以及所請求的資源。

HTTP響應頭

這部分里列出了跨域資源共享(Cross-Origin Resource Sharing)時,服務器端需要返回的響應頭信息.上一部分內容是這部分內容在實際運用中的一個概述.

Access-Control-Allow-Origin
返回的資源需要有一個 Access-Control-Allow-Origin 頭信息,語法如下:
Access-Control-Allow-Origin: <origin> | *
origin參數指定一個允許向該服務器提交請求的URI.對于一個不帶有credentials的請求,可以指定為'',表示允許來自所有域的請求.
舉個栗子,允許來自 http://mozilla.com 的請求,你可以這樣指定:
Access-Control-Allow-Origin: http://mozilla.com
如果服務器端指定了域名,而不是'',那么響應頭的Vary值里必須包含Origin.它告訴客戶端: 響應是根據請求頭里的Origin的值來返回不同的內容的.

Access-Control-Expose-Headers
Requires Gecko 2.0(Firefox 4 / Thunderbird 3.3 / SeaMonkey 2.1)
設置瀏覽器允許訪問的服務器的頭信息的白名單:
Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
這樣, X-My-Custom-Header
和 X-Another-Custom-Header這兩個頭信息,都可以被瀏覽器得到.

Access-Control-Max-Age
這個頭告訴我們這次預請求的結果的有效期是多久,如下:
Access-Control-Max-Age: <delta-seconds>
delta-seconds
參數表示,允許這個預請求的參數緩存的秒數,在此期間,不用發出另一條預檢請求.

Access-Control-Allow-Credentials
告知客戶端,當請求的credientials屬性是true的時候,響應是否可以被得到.當它作為預請求的響應的一部分時,它用來告知實際的請求是否使用了credentials.注意,簡單的GET請求不會預檢,所以如果一個請求是為了得到一個帶有credentials的資源,而響應里又沒有Access-Control-Allow-Credentials頭信息,那么說明這個響應被忽略了.
Access-Control-Allow-Credentials: true | false

帶有credential的請求在上面討論.
Access-Control-Allow-Methods
指明資源可以被請求的方式有哪些(一個或者多個). 這個響應頭信息在客戶端發出預檢請求的時候會被返回. 上面有相關的例子.
Access-Control-Allow-Methods: <method>[, <method>]*

發出預檢請求的例子見上,這個例子里就有向客戶端發送Access-Control-Allow-Methods響應頭信息.

Access-Control-Allow-Headers
也是在響應預檢請求的時候使用.用來指明在實際的請求中,可以使用哪些自定義HTTP請求頭.比如
Access-Control-Allow-Headers: X-PINGOTHER
這樣在實際的請求里,請求頭信息里就可以有這么一條:
X-PINGOTHER: pingpong
可以有多個自定義HTTP請求頭,用逗號分隔.
Access-Control-Allow-Headers: <field-name>[, <field-name>]*

HTTP 請求頭

這部分內容列出來當瀏覽器發出跨域請求時可能用到的HTTP請求頭.注意這些請求頭信息都是在請求服務器的時候已經為你設置好的,當開發者使用跨域的XMLHttpRequest的時候,不需要手動的設置這些頭信息.
Origin
表明發送請求或者預請求的域
Origin: <origin>

參數origin是一個URI,告訴服務器端,請求來自哪里.它不包含任何路徑信息,只是服務器名.
Note: Origin的值可以是一個空字符串,這是很有用的.
注意,不僅僅是跨域請求,普通請求也會帶有ORIGIN頭信息.
Access-Control-Request-Method
在發出預檢請求時帶有這個頭信息,告訴服務器在實際請求時會使用的請求方式
Access-Control-Request-Method: <method>

相關的例子可以在這里找到
Access-Control-Request-Headers
在發出預檢請求時帶有這個頭信息,告訴服務器在實際請求時會攜帶的自定義頭信息.如有多個,可以用逗號分開.
Access-Control-Request-Headers: <field-name>[, <field-name>]*
尊重版權，參考博客Ajax+Spring MVC實現跨域請求（JSONP）,
HTTP訪問控制