2013-05-05 3 views
10

मैं रीस्टफुल एपीआई का उपयोग कर कुछ सेवा के लिए एक वेब एप्लिकेशन लिख रहा हूं। एपीआई https://api.example पर और https://app.example पर ऐप उपलब्ध है। सीओआरएस का उपयोग कर सरल जीईटी अनुरोध क्रोम और फ़ायरफ़ॉक्स में ठीक काम कर रहे हैं। कुछ विधि POST के माध्यम से डेटा स्वीकार करती हैं और स्थान शीर्षलेख में नई यूरी के साथ 303 कोड लौटाती हैं।क्यों ब्राउज़र XMLHTTPRequest और CORS का उपयोग करके रीडायरेक्ट का पालन नहीं करता है?

Preflight विकल्प अनुरोध ठीक है:

Request Method:OPTIONS 
Status Code:200 OK 

अनुरोध हेडर

Accept:*/* 
Accept-Charset:UTF-8,*;q=0.5 
Accept-Encoding:gzip,deflate,sdch 
Accept-Language:en-US,en;q=0.8,ru;q=0.6 
Access-Control-Request-Headers:origin, authorization, content-type 
Access-Control-Request-Method:POST 
Connection:keep-alive 
DNT:1 
Host:api.example 
Origin:https://app.example 
Referer:https://app.example/app/ 
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.32 (KHTML, like Gecko) Chrome/27.0.1425.0 Safari/537.32 SUSE/27.0.1425.0 

प्रतिक्रिया हेडर

Access-Control-Allow-Credentials:true 
Access-Control-Allow-Headers:Authorization, Content-Type 
Access-Control-Allow-Methods:GET,POST,PUT,DELETE,HEAD,OPTIONS 
Access-Control-Allow-Origin:https://app.example 
Access-Control-Expose-Headers:* 
Access-Control-Max-Age:3628800 
Connection:keep-alive 
Content-Length:0 
Date:Sun, 05 May 2013 15:22:50 GMT 
Server:nginx/1.2.5 

तब वास्तविक अनुरोध सिर्फ 303 प्राप्त करने के बाद रोक:

Request URL:https://api.example 
Request Method:POST 
Status Code:HTTP/1.1 303 See Other 

प्रतिक्रिया हेडर:

Server:nginx/1.2.5 
Location:https://api.example/some_url 
Date:Sun, 05 May 2013 15:27:49 GMT 
Content-Type:application/json 
Content-Length:0 
Connection:keep-alive 
Access-Control-Max-Age:3628800 
Access-Control-Expose-Headers:* 
Access-Control-Allow-Origin:https://app.example 
Access-Control-Allow-Methods:GET,POST,PUT,DELETE,HEAD,OPTIONS 
Access-Control-Allow-Headers:Authorization, Content-Type 
Access-Control-Allow-Credentials:true 

आरएफसी उपयोगकर्ता एजेंट द्वारा रीडायरेक्ट का पालन करना चाहिए, लेकिन क्रोम और एफएफ लगता अपेक्षा के अनुरूप व्यवहार नहीं करता है। क्या यह ब्राउज़र का बग है या मैं कुछ गलत कर रहा हूं?

अद्यतन: यदि मैं क्रोमियम शुरू करता हूं - डिस्प्ले-वेब-सुरक्षा सब ठीक काम करता है।

+0

'असली' अनुरोध (सीओआरएस प्री-फ्लाइट नहीं) के लिए आपके अनुरोध शीर्षलेख क्या हैं? मुझे एक बहुत ही समस्या का सामना करना पड़ रहा है। क्या आपने इसे किसी भी मौके से हल किया है? – vrutberg

+2

ऐसा लगता है कि क्रोमियम में इस बग रिपोर्ट से संबंधित हो सकता है https://code.google.com/p/chromium/issues/detail?id=237490 – vrutberg

+0

@vrutberg हाँ यह बिल्कुल वही दिखता है। इसके अलावा यह * कभी-कभी * काम करता है। उदाहरण के लिए, एक एमएसडीएन परीक्षण http://samples.msdn.microsoft.com/ietestcenter/CORS/CORS_014.htm क्रोम और एफएफ दोनों में पास होता है। मेरे एक दोस्त ने बिल्कुल वही कोड लिया और अपने सर्वर पर रख दिया और यह काम नहीं करता! http://twinspect.net/cors.htm – galadog

उत्तर

1

तो यहाँ अपने क्रोमियम बग है अपने कोड पर संभावित त्रुटियों क्रोमियम suport द्वारा दिए गए:

  1. एक ही मूल के अनुरोध एक अलग मूल के एक रीडायरेक्ट का कारण बनता है, तो
    लागू न करें अभिगम नियंत्रण रीडायरेक्ट प्रतिक्रिया
    स्वयं के लिए जांच करता है, क्योंकि अनुरोध के परिणामस्वरूप रीडायरेक्ट
    समान-मूल था।

  2. एक ही मूल के अनुरोध एक अलग मूल के एक रीडायरेक्ट का कारण बनता है, तो
    नई अनुरोध एक अद्वितीय सुरक्षा मूल का उपयोग नहीं करते के लिए मूल रूप मूल अनुरोध के URL का उपयोग करें।

  3. ट्रैक है कि क्लाइंट (जैसे कि, XMLHttpRequest) वास्तव में अनुरोध किया
    कि साख पहली जगह में भेजा जाए। जब समान-मूल अनुरोध किसी भिन्न मूल पर रीडायरेक्ट करता है, तो मूल अनुरोध कुकीज़ भेजेगा या नहीं, क्योंकि यह समान-मूल है। नया क्रॉस-मूल अनुरोध कुकीज़ को तब तक नहीं भेजना चाहिए जब तक उनका अनुरोध नहीं किया गया था, ताकि पर एक्सेस कंट्रोल चेक "एक्सेस-कंट्रोल-अनुमति-उत्पत्ति = *" प्रदान करने पर प्रतिक्रिया सफल हो जाएगी।

+0

मेरा मानना ​​है कि उनकी समस्या में एक ही मूल अनुरोध शामिल नहीं था। यह एक क्रॉस-मूल अनुरोध था जिसमें 302 प्रतिक्रिया थी। –

13

मैं भी इसके साथ कुश्ती कर रहा हूं। ऐसा प्रतीत होता है कि preflighted CORS अनुरोधों के लिए 3xx रीडायरेक्ट spec द्वारा प्रतिबंधित हैं।

http://www.w3.org/TR/cors/

कल्पना से

:

(चरण 1. और 2. विस्तार preflighting प्रक्रिया और हम कदम के लिए आते हैं ...।)

... 3। यह वास्तविक अनुरोध है। अनुरोध करने के दौरान अनुरोध करें और अनुरोध नियम अनुरोध करते समय अनुरोध नियमों का पालन करें।

प्रतिक्रिया 301, 302, 303, 307, या 308 का HTTP स्थिति कोड लागू करें cache and network error steps है।

और फिर अगर हम http://www.w3.org/TR/cors/#cache-and-network-error-steps करने के लिए नीचे पर स्क्रॉल:

चरणों जब भी नेटवर्क त्रुटि लागू होते हैं, एल्गोरिथ्म कि कदम के इस सेट लागू समाप्त और पार मूल अनुरोध स्थिति सेट नेटवर्क त्रुटि के लिए ।

नोट: इसका उपयोगकर्ता प्रमाण-पत्रों की स्थापना पर कोई प्रभाव नहीं पड़ता है। अर्थात। यदि ब्लॉक कुकीज़ ध्वज अनसेट है, तो कुकीज़ प्रतिक्रिया द्वारा सेट की जाएगी।

चरणों जब भी कैश और नेटवर्क त्रुटि लागू होते हैं, इन चरणों का पालन करें:

preflight परिणाम कैश जहां मूल क्षेत्र मूल्य स्रोत मूल और यूआरएल के लिए एक केस-संवेदी मिलान है में प्रविष्टियाँ निकालें फ़ील्ड मान अनुरोध URL के लिए केस-संवेदी मिलान है।

नेटवर्क त्रुटि चरणों को लागू करें जैसे एल्गोरिदम ने को कैश किया और कैश और नेटवर्क त्रुटि चरणों ने नेटवर्क त्रुटि चरणों को लागू किया।

(जोर दस्तावेज़ से लिया।)

3xx रीडायरेक्ट, तथापि, सरल CORS अनुरोधों के लिए अनुमति दी जाती है।

संबंधित मुद्दे

 संबंधित मुद्दे