JS跨域(Access-Control-Allow-Origin)前後端解決方案詳解
瀏覽器的同源安全策略
同源策略,它是由Netscape提出的一個著名的安全策略。現在所有支援的瀏覽器都會使用這個策略。所謂同源是指,域名,協議,埠相同。同源策略是瀏覽器的行為,是為了保護本地資料不被Script程式碼獲取回來的資料汙染,因此攔截的是客戶端發出的請求回來的資料接收,即請求傳送了,伺服器響應了,但是無法被瀏覽器接收。
同源:協議 + 域名 + 埠。所以,怎麼才算跨域呢?
什麼是跨域
什麼是跨域,簡單地理解就是因為JavaScript同源策略的限制,a.com 域名下的無法操作b.com或是c.a.com域名下的物件。更詳細的說明可以看下錶:
URL | 說明 | 是否允許通訊 |
---|---|---|
http://www.a.com/a.js | 同一域名下 | 允許 |
http://www.a.com/lab/a.js http://www.a.com/script/b.js | 同一域名下不同資料夾 | 允許 |
http://www.a.com:8000/a.js http://www.a.com/b.js | 同一域名,不同埠 | 不允許 |
http://www.a.com/a.js https://www.a.com/b.js | 同一域名,不同協議 | 不允許 |
http://www.a.com/a.js http://70.32.92.74/b.js | 域名和域名對應ip | 不允許 |
http://www.a.com/a.js http://script.a.com/b.js | 主域相同,子域不同 | 不允許 |
http://www.a.com/a.js http://a.com/b.js | 同一域名,不同二級域名(同上) | 不允許(cookie這種情況下也不允許訪問) |
//www.jb51.net/a.js http://www.a.com/b.js | 不同域名 | 不允許 |
特別注意兩點:
第一,如果是協議和埠造成的跨域問題“前臺”是無能為力的,
第二:在跨域問題上,域僅僅是通過“URL的首部”來識別而不會去嘗試判斷相同的ip地址對應著兩個域或兩個域是否在同一個ip上。
“URL的首部”指window.location.protocol +window.location.host,也可以理解為“Domains,protocols and ports must match”。
一、前端跨域解決方法(JavaScript)
接下來簡單地總結一下在“前臺”一般處理跨域的辦法
1、document.domain+iframe的設定
對於主域相同而子域不同的例子,可以通過設定document.domain的辦法來解決。具體的做法是可以在http://www.a.com/a.html和http://script.a.com/b.html兩個檔案中分別加上document.domain = ‘a.com’;然後通過a.html檔案中建立一個iframe,去控制iframe的contentDocument,這樣兩個js檔案之間就可以“互動”了。當然這種辦法只能解決主域相同而二級域名不同的情況,如果你異想天開的把script.a.com的domian設為alibaba.com那顯然是會報錯地!程式碼如下:
www.a.com上的a.html
dohttp://www.cppcns.comcument.domain = 'a.com'; var ifr = document.createElement('iframe'); ifr.src = 'http://script.a.com/b.html'; ifr.style.display = 'none'; document.body.appendChild(ifr); ifr.onload = function(){ var doc = ifr.contentDocument || ifr.contentWindow.document; // 在這裡操縱b.html alert(doc.getElementsByTagName("h1")[0].childNodes[0].nodeValue); };
script.a.com上的b.html
document.domain = 'a.com';
這種方式適用於{www.jb51.com,jb51.com,script.jb51.com,.jb51.com}中的任何頁面相互通訊。
備註:某一頁面的domain預設等於window.location.hostname。主域名是不帶www的域名,例如a.com,主域名前面帶字首的通常都為二級域名或多級域名,例如www.a.com其實是二級域名。 domain只能設定為主域名,不可以在b.a.com中將domain設定為c.a.com。
問題:
1、安全性,當一個站點(b.a.com)被攻擊後,另一個站點(c.a.com)會引起安全漏洞。
2、如果一個頁面中引入多個iframe,要想能夠操作所有iframe,必須都得設定相同domain。
2、動態建立script
雖然瀏覽器預設禁止了跨域訪問,但並不禁止在頁面中引用其他域的JS檔案,並可以自由執行引入的JS檔案中的function(包括操作cookie、Dom等等)。根據這一點,可以方便地通過建立script節點的方法來實現完全跨域的通訊。
這裡判斷script節點載入完畢還是蠻有意思的:ie只能通過script的readystatechange屬性,其它瀏覽器是script的load事件。以下是部分判斷script載入完畢的方法。
js.onload = js.onreadystatechange = function() { if (!this.readyState || this.readyState === 'loaded' || this.readyState === 'complete') { // callback在此處執行 js.onload = js.onreadystatechange = null; } };
3、利用iframe和location.hash
這個辦法比較繞,但是可以解決完全跨域情況下的腳步置換問題。原理是利用location.hash來進行傳值。在url: http://a.com#helloword中的‘#helloworld’就是location.hash,改變hash並不會導致頁面重新整理,所以可以利用hash值來進行資料傳遞,當然資料容量是有限的。假設域名a.com下的檔案cs1.html要和jb51.net域名下的cs2.html傳遞資訊,cs1.html首先建立自動建立一個隱藏的iframe,iframe的src指向jb51.net域名下的cs2.html頁面,這時的hash值可以做引數傳遞用。cs2.html響應請求後再將通過修改cs1.html的hash值來傳遞資料(由於兩個頁面不在同一個域下IE、Chrome不允許修改parent.location.hash的值,所以要藉助於a.com域名下的一個代理iframe;Firefox可以修改)。同時在cs1.html上加一個定時器,隔一段時間來判斷location.hash的值有沒有變化,一點有變化則獲取獲取hash值。程式碼如下:
先是a.com下的檔案cs1.html檔案:
function startRequest(){ var ifr = document.createElement('iframe'); ifr.style.display = 'none'; ifr.src = '//www.jb51.net/lab/cscript/cs2.html#paramdo'; document.body.appendChild(ifr); } function checkHash() { try { var data = location.hash ? location.hash.substring(1) : ''; if (console.log) { console.log('Now the data is '+data); } } catch(e) {}; } setInterval(checkHash,2000);
jb51.net域名下的cs2.html:
//模擬一個簡單的引數處理操作 switch(location.hash){ case '#paramdo': callBack(); break; case '#paramset': //do something…… break; } function callBack(){ try { parent.location.hash = 'somedata'; } catch (e) { // ie、chrome的安全機制無法修改parent.location.hash, // 所以要利用一箇中間的cnblogs域下的代理iframe var ifrproxy = document.createElement('iframe'); ifrproxy.style.display = 'none'; ifrproxy.src = 'http://a.com/test/cscript/cs3.html#somedata'; // 注意該檔案在"a.com"域下 document.body.appendChild(ifrproxy); } }
a.com下的域名cs3.html
//因為parent.parent和自身屬於同一個域,所以可以改變其location.hash的值 parent.parent.location.hash = self.location.hash.substring(1);
當然這樣做也存在很多缺點,諸如資料直接暴露在了url中,資料容量和型別都有限等……
4、window.name實現的跨域資料傳輸
文章較長列在此處不便於閱讀,詳細請看window.name實現的跨域資料傳輸。
5、使用HTML5 postMessage
HTML5中最酷的新功能之一就是跨文件訊息傳輸Cross Document Messaging。下一代瀏覽器都將支援這個功能:Chrome 2.0+、Internet Explorer 8.0+,Firefox 3.0+,Opera 9.6+,和 Safari 4.0+ 。 Facebook已經使用了這個功能,用postMessage支援基於web的實時訊息傳遞。
otherWindow.postMessage(message,targetOrigin);
otherWindow:對接收資訊頁面的window的引用。可以是頁面中iframe的contentWindow屬性;window.open的返回值;通過name或下標從window.frames取到的值。
message:所要傳送的資料,string型別。
targetOrigin:用於限制otherWindow,“*”表示不作限制
a.com/index.html中的程式碼:
<iframe id="ifr" src="b.com/index.html"></iframe> <script type="text/javascript"> window.onload = function() { var ifr = document.getElementById('ifr'); var targetOrigin = 'http://b.com'; // 若寫成'http://b.com/c/proxy.html'效果一樣 // 若寫成'http://c.com'就不會執行postMessage了 ifr.contentWindow.postMessage('I was there!',targetOrigin); }; </script>
b.com/index.html中的程式碼:
<script type="text/javascript"> window.addEventListener('message',function(event){ // 通過origin屬性判斷訊息來源地址 if (event.origin == 'http://a.com') { alert(event.data); // 彈出"I was there!" alert(event.source); // 對a.com、index.html中window物件的引用 // 但由於同源策略,這裡event.source不可以訪問window物件 } },false); </script>
二、後臺跨域解決方案
CORS
這是W3C的標準,全稱是"跨域資源共享"(Cross-origin resource sharing)。
//指定允許其他域名訪問 ‘Access-Control-Allow-Origin:http://172.20.0.206'//一般用法(,指定域,動態設定),3是因為不允許攜帶認證頭和cookies //是否允許後續請求攜帶認證資訊(cookies),該值只能是true,否則不返回 ‘Access-Control-Allow-Credentials:true'
上面第一行說到的Access-Control-Allow-Origin有多種設定方法:
設定是最簡單粗暴的,但是伺服器出於安全考慮,肯定不會這麼幹,而且,如果是的話,遊覽器將不會發送cookies,即使你的XHR設定了withCredentials
指定域,如上圖中的http://172.20.0.206,一般的系統中間都有一個nginx,所以推薦這種
動態設定為請求域,多人協作時,多個前端對接一個後臺,這樣很方便。
Response支援跨域
從上面控制檯的輸出可以看到,錯誤原因是請求的資源(介面)的header中沒有”Access-Control-Allow-Origin“,那我們可以給它加上。在哪加?既然說是請求的資源沒有,那當然是在請求的資源上加,也就是服務端。
@SpringBootApplication @Configuration @RestController public class ApplicationA { public static void main(String[] args) { SpringApplication.run(ApplicationA.class,args); } @RequestMapping("/test") public Object test(HttpServletRequest request,HttpServletResponse response) { // 跨域支援 response.setHeader("Access-Control-Allow-Origin","*"); response.setHeader("Access-Control-Allow-Methods","POST,GET,PUT,DELETE"); response.setHeader("Access-Control-Max-Age","3600"); response.setHeader("Access-Control-Allow-Headers","*"); response.setHeader("Access-Control-Allow-Credentials","true"); Map<String,Object> map = new HashMap<>(); map.put("success",true); map.put("msg","我來自服務端"); return map; } }
springboot支援跨域
測試用例是一個springboot專案,可以用更簡單的方式。通過一個繼承了WebMvcConfigurerAdapter的bean,重寫addCorsMappings方法,在方法裡配置。
@SpringBootApplication
@Configuration
@RestController
public class ApplicationA extends WebMvcConfigurerAdapter {
public static void main(String[] args) {
SpringApplication.run(ApplicationA.class,HttpServletResponse response) {
Map<String,"我來自服務端");
return map;
}
// 跨域支援
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("*")
.allowCredentials(true)
.allowedMethods("GET","http://www.cppcns.comPOST","DELETE","PUT")
.maxAge(3600);
}
Java中設定多個Access-Control-Allow-Origin跨域訪問
1、如果服務端是Java開發的,新增如下設定允許跨域即可,但是這樣做是允許所有域名都可以訪問,不夠安全。
response.setHeader(“Access-Control-Allow-Origin”,"*");
2、為保證安全性,可以只新增部分域名允許訪問,新增位置可以在下面三處任選一個。
(1)可以在過濾器的filter的dofilter()方法種設定。
(2)可以在servlet的get或者post方法裡面設定。
(3)可以放在訪問的jsp頁面第一行。
3、在此用第一種方法,注意web.xml配置過濾器(filter)。
public void doFilter(ServletRequest req,ServletResponse res,FilterChain chain) throws IOException,ServletException { // 將ServletResponse轉換為HttpServletResponse HttpServletResponse httpResponse = (HttpServletResponse) res; // 如果不是80埠,需要將埠加上,如果是叢集,則用Nginx的地址,同理不是80埠要加上埠 String [] allowDomain= {"http://www.baidu.com","http://123.456.789.10","http://123.16.12.23:8080"}; Set allowedOrigins= new HashSet(Arrays.asList(allowDomain)); String originHeader=((HttpServletRequest) req).getHeader("Origin"); if (allowedOrigins.contains(originHeader)){ httpResponse.setHeader("Access-Control-Allow-Origin",originHeader); httpResponse.setContentType("application/json;charset=UTF-8"); httpResponse.setHeader("Access-Control-Allow-Methods",OPTIONS,DELETE"); httpResponse.setHeader("Access-Control-Max-Age","3600"); httpResponse.setHeader("Access-Control-Allow-Headers","Content-Type,Access-Token"); // 如果要把Cookie發到伺服器,需要指定Access-Control-Allow-Credentials欄位為true httpResponse.setHeader("Access-Control-Allow-Credentials","true"); httpResponse.setHeader("Access-Control-Expose-Headers","*"); } chain.doFilter(req,res); }
基於nginx配置請求的CORS
目前很多請求都不是直接暴露的,很多通過nginx做反向代理,因此可以使用nginx配置固定請求的Access-Control-Allow-Origin,實現跨域訪問。方式是在被請求的介面,配置location代理,新增header實現。
#活動訪問介面跨域配置 location /promotion/activityPro { proxy_pass http://frontHost/promotion/activityPro; add_header 'Access-Control-Allow-Origin' '*'; #add_header 'Access-Control-Allow-Methods' 'GET,POST'; #add_header 'Access-Control-Allow-Credentials' "true"; #add_header 'Access-Control-Max-Age' 86400; #add_header 'Access-Control-Allow-Header' 'Content-Type,*'; }
三、前端跨域JSONP方案
有前端經驗的童鞋知道,有時我們會在自己的程式碼裡直接引入其它域名的js、css等靜態檔案。為啥這些靜態檔案沒被瀏覽器限制呢?通常為了減輕web伺服器的壓力,我們會把js、css,img等靜態資源分離到另一臺獨立域名的伺服器上,使其和前端分離開。基於這個原因,瀏覽器並沒有限制這類靜態資源的跨域訪問。
我們可以動態地建立一個script,讓瀏覽器以為我們要獲取靜態資源,從而網開一面。而伺服器端也需要做一點改變,不能直接返回json,而是返回一個立即執行的函式,而前端請求的結果就作為函式的引數。
後端介面返回
@SpringBootApplication @Configuration @RestController public class ApplicationA { public static void main(String[] args) { SpringApplication.run(ApplicationA.class,args); } @RequestMapping("/test") public String test(HttpServletRequest request,HttpServletResponse response,String callback) throws IOException { Map<String,"我來自服務端"); // 返回值如下: // callback({"msg":"我來自服務端","success":true}); return String.format("%s(%s);",callback,JsonUtil.toJson(map)); }
js原生實現jsonp
function test() { // 外部域名,引數是和後端介面約定的callback指定介面返回後的回撥函式 url = "http://localhost:8882/test?callback=_ajax_callback"; // 建立一個script元素 var script = document.createElement('script'); script.type = 'text/javascript'; script.src = url; document.head.appendChild(script); } // 介面回撥 function _ajax_callback(res) { console.log("被回調了"); console.log(res); }
實現jsonp
$.ajax({ url: 'http://localhost:8882/test',type: 'get',dataType: 'jsonp',// 請求方式 jsonpCallback: "_ajax_callback",// 回撥函式名 data: {} });
.js實現jsonp
this.$http.jsonp(‘http://localhost:8882/test',{undefined params: {},jsonp: ‘_ajax_callback客棧' }).then((res) => {undefined console.log(res); })
JSONP的優缺點
優點:它不像XMLHttpRequest物件實現的Ajax請求那樣受到同源策略的限制;它的相容性更好,在更加古老的瀏覽器中都可以執行,不需要XMLHttpRequest或ActiveX的支援;並且在請求完畢後可以通過呼叫callback的方式回傳結果。
缺點:它只支援GET請求而不支援POST等其它型別的HTTP請求;它只支援跨域HTTP請求這種情況,不能解決不同域的兩個頁面之間如何進行JavaScript呼叫的問題。
其它方式支援跨域
nginx反向代理:前端訪問相同域名,nginx再根據需要把請求轉發到外部域名;
後端代理:在後端接口裡先請求外部資源(比如用HttpClient),然後把結果返回給前端,這樣就不是跨域了;
其它:藉助iframe、postMessage等也可實現跨域。
document.domain,window.name,web sockets
更多關於瀏覽器跨域解決方案請檢視下面的相關連結