CORSプリフライトリクエスト（DjangoとAngular）

Question

私はREST APIにリクエストしようとしています。これはCORS要求です。 私のフロントエンド：角1.5（localhostを：3000） マイバックエンド：ジャンゴ（。***** ddns.net）

だから私はコードを共有したくない誰かによって作られたサービスを（使用していますこれは、実際のリクエスト（プリフライト）の前にOPTIONSリクエストを行っていることを意味します。正確には、UIルーターの状態定義の解決オプションを使用して呼び出します。

これを行うにはDjangoにCORSがあります。 Google Chromeで取得するエラーです：

XMLHttpRequest cannot load https://****.net/api/myprofile. The request was redirected to 'https://*****.net/punchclock/api/myprofile/', which is disallowed for cross-origin requests that require preflight. 

コントローラで古典的な$ httpリクエストを行うと、働いている。

この要求は私のジャンゴを受け取っです：

+6655:5740d0f9:10| 
OPTIONS /punchclock/api//myprofile HTTP/1.0| 
Host:*****.net| 
Connection:close| 
Pragma:no-cache| 
Cache-Control:no-cache| 
Access-Control-Request-Method:GET| 
Origin:http%3a//localhost%3a3000| 
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36| 
Access-Control-Request-Headers:accept, authorization| 
Accept:*/*| 
Referer:http%3a//localhost%3a3000/dashboard| 
Accept-Encoding:gzip, deflate, sdch| 
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4,es;q=0.2 
-6655:5740d0f9:10 

そして、これは私が、私は郵便配達でそれを行う場合には（私はOPTIONS要求を行うとき、それは郵便配達で作業している）を得る反応である

Access-Control-Allow-Headers →x-requested-with, content-type, accept, origin, authorization, x-csrftoken 
Access-Control-Allow-Methods →GET, POST, PUT, PATCH, DELETE, OPTIONS 
Access-Control-Allow-Origin →* 
Access-Control-Max-Age →86400 
Allow →GET, HEAD, OPTIONS 
Connection →keep-alive 
Content-Type →application/json 
Date →Sat, 21 May 2016 21:15:02 GMT 
Server →nginx/1.6.2 
Transfer-Encoding →chunked 
Vary →Accept 
X-Frame-Options →SAMEORIGIN 

を

私はそれがジャンゴの側の問題だと思います。あなたは何か考えている...（私はCORSについてたくさん学ぶ必要があります）

Answer 1

あなたが送信しているヘッダーの一部が許可されていない可能性があります。確認するには、Google Chromeデバッガに行き、リクエストヘッダーをコピーして、郵便配達員を使用して送信してください。失敗した場合は、許可されていないものが見つかるまでヘッダーを削除します。

similar answer hereがあります。具体的にどこに提出されたヘッダが許可され、ヘッダーと一致しない場合

W3 CORS Spec Section 6.2 Preflight Requestsによると、プリフライトが要求を拒否しなければならないと言います。

Answer 2

アクセス制御許可元はCORS (Cross-Origin Resource Sharing) headerです。

サイトAがサイトBからコンテンツを取得しようとすると、サイトBは、このページのコンテンツが特定の発信元からアクセス可能であることをブラウザに伝えるために、アクセス制御許可原点応答ヘッダーを送信できます。 （原点はドメインであり、スキームとポート番号です。）デフォルトでは、サイトBのページには他の起点からアクセスできません。 Access-Control-Allow-Originヘッダーを使用すると、特定の要求元からのクロスオリジンアクセスの扉が開きます。サイトBがサイトAにアクセスできるように望んでいることを各リソース/ページに対して

、サイトBは、レスポンスヘッダとそのページを提供する必要があります

Access-Control-Allow-Origin: http://siteA.com 

最近のブラウザは完全にクロスドメインリクエストをブロックしません。サイトAがサイトBからページを要求する場合、ブラウザは実際に要求されたページをネットワークレベルでフェッチし、応答ヘッダーがサイトAを許可されたリクエスタドメインとしてリストしているかどうかを確認します。サイトBがサイトAがこのページにアクセスすることを許可されていないと示している場合、ブラウザはXMLHttpRequestのエラーイベントをトリガーし、要求しているJavaScriptコードへの応答データを拒否します。

非シンプルなリクエスト：ネットワークレベルで何が起こる

は、上述よりも少し複雑になることがあります。要求が「単純でない」要求である場合、ブラウザはまずサーバーが要求を受け入れることを検証するために、データなしの「プリフライト」OPTIONS要求を送信します。

non-simple requestヘッダーを使用してGETまたはPOST（例：PUT、DELETE）以外のHTTP動詞を使用している場合、要求は単純ではありません。受諾可能 - 言語コンテンツ - 言語のコンテンツタイプ（これは値がapplication/x-www-form-urlencoded、multipart/form-data、またはtext/plainの場合にのみ簡単です）サーバ非単純動詞および/または単純でないヘッダーに一致する適切な応答ヘッダー（非単純ヘッダーの場合はAccess-Control-Allow-Headers、非単純動詞の場合はAccess-Control-Allow-Methods）をOPTIONSプリフライトに応答します、ブラウザは実際の要求を送信します。

サイトAは、アプリケーション/ JSONの非シンプルなContent-Typeの値で、/ somePageのためのPUTリクエストを送信したい、ブラウザが最初のプリフライトリクエストを送信したとすると：

OPTIONS /somePage HTTP/1.1 
Origin: http://siteA.com 
Access-Control-Request-Method: PUT 
Access-Control-Request-Headers: Content-Type 

注意していることAccess-Control-Request-MethodとAccess-Control-Request-Headersがブラウザによって自動的に追加されます。それらを追加する必要はありません。このOPTIONSプリフライトは成功したレスポンスヘッダ

Access-Control-Allow-Origin: http://siteA.com 
Access-Control-Allow-Methods: GET, POST, PUT 
Access-Control-Allow-Headers: Content-Type 

（プリフライトが行われた後に）実際の要求を送信

を取得し、動作が単純な要求の処理方法と同じです。言い換えれば、プリフライトが成功した単純ではない要求は、単純な要求と同じように扱われる（すなわち、サーバは実際の応答のために依然として Access-Control-Allow-Originを送信しなければならない）。

のブラウザでは、実際の要求送信します

PUT /somePage HTTP/1.1 
Origin: http://siteA.com 
Content-Type: application/json 

{ "myRequestContent": "JSON is so great" } 

を、サーバが、それは単純な要求のためのと同じように、Access-Control-Allow-Originを送り返し：

Access-Control-Allow-Origin: http://siteA.com 

について少し詳しくUnderstanding XMLHttpRequest over CORSを参照してください。単純ではない要求。

私は、CORSの問題と解決策をよりよく理解するのに役立つと思います。