Access control allow orgin簡単な要求と複雑な要求

エラーメッセージ:
XMLHttp Request cannot loadhttp://web.image.myqcloud.com/photos/v2/10008653/bhpocket/0/?sign=4FcLKd5B8…p 4 SkFVUEJtZ 1 mZ 0 xNDQ 0 NzExMDAE 5 JnQ 9 MTQ 0 NDcwNzQOSxOZyPTEzMDMDMgzOT AmdT 0 wJmY 9.No'Access-Origin'header is present on the requested Oness.gine.http://localhost'is therefore not allowed access.
 
分析:
Access control allow orginは直訳して「アクセス制御許容同源」となります.これはajaxのドメイン横断アクセスによるものです.ドメインをまたぐということは、a.comドメインの下でb.comドメインのリソースにアクセスすることです.セキュリティの観点から、ブラウザはドメインをまたいで書くことができます.ドメインをまたいで読むことができません.書き込みは上りで、要求を送ります.send requestは下りで読んで、応答を受け入れます.この二つの規則を理解したら、以下の現象も理解できます.
 
1、フォームのデフォルト提出(get、post)、ハイパーリンクが域外のリソースにアクセスすることは許可されています.ボタン/ハイパーリンクをクリックした時に、ブラウザのアドレスが変更されました.これは一般的な要求であり、ドメインをまたぐことはありません.
2、ajax(xmlhttprequestを借りる)ドメイン横断要求は禁止されています.ajaxは応答を受け入れるために、これは違反しています.
3、jsonpはドメインをまたいで読んで、形式はGET方式に制限して、それはscriptタグの特性を利用しました.これは許可です.ブラウザはドメインをまたいでスクリプトを読むので、例外として、同じようなSrcは域外資源を要求できます.
 
ソリューション:
シナリオ1、chromeブラウザにパラメータを追加します.--disable-web-security


 
シナリオ2
a
IEブラウザではなく、xmlhttprequestを利用して、request headerにorigginを追加します.このドメイン名のアドレスは、通常は手動で追加する必要がありません.ブラウザが自動的に追加されます.
IEブラウザは、XDomainRequestを利用して要求を送信し、自動的にheaderにオリジンを追加します.
b、レスポンスheader追加access-control-allow-origgin:*
 
ドメイン別デモンストレーションとコード
検証プロセスは、まずhttp:/本機ip:port/projectにアクセスします.name/a.jsp、a.jspはajax要求を送信して、http://localhost:port/project_name/b.jsp、このようにドメインを跨ぐ問題を生みました.
a.jsp
 

$(document).ready(function() {
	
	$.getJSON('http://localhost/test_maven/b.jsp', function(data) {
		alert("request succeed");
	});
});

 
 
b.jsp

 
レスポンス.set Header(「Access-Coontrol-Origin」)を注釈したら、access control allow origginエラーが発生します.ワイルドカード*を使用して、ドメイン間のすべてのアクセスが可能になりましたので、ドメイン間のアクセスに成功しました.
しかし、ワイルドカード*を使用すると、任意のドメインからのクロスドメイン要求のアクセスが成功することができますので、危険ですので、生産環境では通常より正確にコントロールします.
 
簡単なお願い
上記の要求は簡単な要求です.Access-Coontrol-Origin:*を追加すれば、アクセスが成功します.複雑な要求なら、さらなる処理が必要で、成功できます.ここではまず簡単な要求と複雑な要求とは何かを説明します.
 

Simple requests

A simple cross-site request is one that meets all the following conditions:

The only allowed methods are:
GET
HEAD
POST
Apart from the headers set automatically by the user agent (e.g. Connection, User-Agent, etc.), the only headers which are allowed to be manually set are:
Accept
Accept-Language
Content-Language
Content-Type
The only allowed values for the Content-Type header are:
application/x-www-form-urlencoded
multipart/form-data
text/plain

 
 
 
簡単に言えば、上記の条件に該当するのは全部「簡単な要求」で、簡単な要求を除いては「複雑な要求」です.
 
 
複雑な要求
正式なpostの前に、ブラウザはまず一つのoptions要求(preflightともいいます)を出します.同時にheaderはorignとAccess-Coontrol-request-*:＊などのヘッドを持って、サーバーの応答は相応のaccess-control-allow-orginに戻ります.マッチングすると、ブラウザは正式なpostを送ります.これも解答しました.ドメインをまたいで訪問する時、私達は明らかに発送したポストの要請です.失敗したら、chrome networkを調べたら、options方法の原因が分かります.
上記のプロセスによれば、バックグラウンド方法は、追加的にoptions方法を必要とし、以下はテストサンプルである.
ここのcontent-typeは(appication/x-wn-form-urlencoded、multiipad/form-data、text/plin)のいずれにも属さないので、複雑な要求です.
 
 

 $.ajax({
		   
           type: "post",
           url: "http://localhost/test_maven/a_action",
           contentType: "application/json",
           dataType:  "json",
           success: function(){
				alert("request succeed");
			}
       });

 
 
 
 
 
 

	@RequestMapping(value = "/a_action",
			method=RequestMethod.OPTIONS)
	public void aActionOption(HttpServletResponse response ) throws IOException{
		
		System.out.println("option execute.....");
		response.setHeader("Access-Control-Allow-Headers", "accept, content-type");
		response.setHeader("Access-Control-Allow-Method", "POST");
		response.setHeader("Access-Control-Allow-Origin", "http://192.168.8.36");
	}

 

@RequestMapping(value = "/a_action",method=RequestMethod.POST)
	public void aAction(HttpServletResponse response ) throws IOException{
		
		System.out.println("a_action execute.....");
	}

最初はoptions要求で、http options要求はget、post、headなどと同じで、httpの要求方法、options方法で、サーバー側のあるurlサポートの方法を取得します.reponse headerのallowフラグがサポートする方法です.
 
 
 

 
二回目が本当のお願いです.
 

 
この案はw 3 cの最新仕様を利用しているので、この方案はブラウザの実現に依存している.
 
まとめ:
Access control allow orginエラーが発生しました.ドメイン横断要求の失敗です.ブラウザの送信要求は成功しました.ブラウザも応答を受信しましたが、XmlHttpRquestの受信要求を制限しました.xmlhttprequestに応答を受けさせません.そして、jsコンソールでエラーを報告します.これはつまり、私たちがネットワークコンソールでhttpの状態コードが200に見えるが、jsコンソールでjsエラーが発生した原因です.
 
参考:
「白い帽子はwebの安全を話します」P 28、P 124 cross origings sharringの内容
ドメインをまたぐpost要求実現方案のまとめ--転
CORS
 
9年の全スタック開発経験は、個人番号に注目してください.