आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी
सीओआरएस (क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग) एक स्टैंडर्ड तरीका है. इसकी मदद से, किसी वेब पेज में JavaScript XMLHttpRequest (XHR) कॉल को, नॉन-ऑरिजिन डोमेन के रिसॉर्स के साथ इंटरैक्ट करने की अनुमति मिलती है. सीओआरएस, "एक ही ऑरिजिन की नीति" को लागू करने का एक सामान्य तरीका है. यह नीति सभी ब्राउज़र लागू करते हैं. उदाहरण के लिए, अगर आपने अपने ब्राउज़र में JavaScript कोड का इस्तेमाल करके, Twitter API को XHR कॉल किया है, तो कॉल पूरा नहीं होगा. ऐसा इसलिए होता है, क्योंकि आपके ब्राउज़र को पेज दिखाने वाला डोमेन, Twitter API को पेज दिखाने वाले डोमेन से अलग होता है. सीओआरएस, इस समस्या का समाधान करता है. यह सर्वर को "ऑप्ट-इन" करने की अनुमति देता है, ताकि वे क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग की सुविधा दे सकें.
वीडियो: एपीआई प्रॉक्सी पर CORS चालू करने का तरीका जानने के लिए, यह छोटा वीडियो देखें.
CORS के इस्तेमाल का सामान्य उदाहरण
नीचे दिया गया JQuery कोड, काल्पनिक टारगेट सेवा को कॉल करता है. अगर इस फ़ंक्शन को ब्राउज़र (वेब पेज) के कॉन्टेक्स्ट में लागू किया जाता है, तो एक ऑरिजिन से दूसरे ऑरिजिन के बीच नेटवर्क मैसेज भेजने से जुड़ी नीति की वजह से कॉल पूरा नहीं होगा:
<script> var url = "http://service.example.com"; $(document).ready(function(){ $("button").click(function(){ $.ajax({ type:"GET", url:url, async:true, dataType: "json", success: function(json) { // Parse the response. // Do other things. }, error: function(xhr, status, err) { // This is where we end up! } }); }); }); </script>
इस समस्या को हल करने का एक तरीका यह है कि Apigee API प्रॉक्सी बनाई जाए. यह प्रॉक्सी, बैक एंड पर मौजूद सेवा एपीआई को कॉल करती है. ध्यान रखें कि Edge, क्लाइंट (इस मामले में ब्राउज़र) और बैकएंड एपीआई (सेवा) के बीच में होता है. एपीआई प्रॉक्सी, ब्राउज़र में नहीं, बल्कि सर्वर पर काम करती है. इसलिए, यह सेवा को कॉल कर सकती है. इसके बाद, आपको सिर्फ़ TargetEndpoint रिस्पॉन्स में सीओआरएस हेडर अटैच करने हैं. जब तक ब्राउज़र सीओआरएस के साथ काम करता है, तब तक ये हेडर ब्राउज़र को यह सिग्नल देते हैं कि एक ऑरिजिन से दूसरे ऑरिजिन के बीच नेटवर्क मैसेज भेजने से जुड़ी नीति को "कम" किया जा सकता है. इससे क्रॉस-ऑरिजिन एपीआई कॉल पूरा हो पाता है.
CORS के साथ काम करने वाली प्रॉक्सी बनाने के बाद, क्लाइंट-साइड कोड में बैकएंड सेवा के बजाय, एपीआई प्रॉक्सी यूआरएल को कॉल किया जा सकता है. उदाहरण के लिए:
<script> var url = "http://myorg-test.apigee.net/v1/example"; $(document).ready(function(){ $("button").click(function(){ $.ajax({ type:"GET", url:url, async:true, dataType: "json", success: function(json) { // Parse the response. // Do other things. }, error: function(xhr, status, err) { // This time, we do not end up here! } }); }); }); </script>
नई एपीआई प्रॉक्सी में CORS नीति जोड़ना
एपीआई प्रॉक्सी बनाते समय, उसमें "Add CORS" नीति जोड़कर, सीओआरएस की सुविधा जोड़ी जा सकती है. इस नीति को जोड़ने के लिए, Build a Proxy विज़र्ड के सुरक्षा पेज पर मौजूद, सीओआरएस हेडर जोड़ें चेकबॉक्स को चुनें.
इस चेकबॉक्स को चुनने पर, सिस्टम में Add CORS नाम की नीति अपने-आप जुड़ जाती है. साथ ही, इसे TargetEndpoint के रिस्पॉन्स प्रीफ़्लो से जोड़ दिया जाता है. इसे यहां दिए गए डायग्राम में दिखाया गया है:

Add CORS नीति को AssignMessage नीति के तौर पर लागू किया जाता है. यह नीति, रिस्पॉन्स में सही हेडर जोड़ती है. असल में, हेडर से ब्राउज़र को यह पता चलता है कि वह किन ऑरिजिन के साथ अपने संसाधन शेयर करेगा, किन तरीकों को स्वीकार करेगा वगैरह. इन सीओआरएस हेडर के बारे में ज़्यादा जानने के लिए, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग के लिए W3C के सुझाव पढ़ें.
आपको नीति में इस तरह बदलाव करना चाहिए:
- नीचे दिए गए कोड के स्निपेट में दिखाए गए तरीके से,
content-typeऔरauthorizationहेडर (बुनियादी पुष्टि या OAuth2 के लिए ज़रूरी है) कोAccess-Control-Allow-Headersहेडर में जोड़ें. - OAuth2 की पुष्टि करने के लिए, आपको आरएफ़सी के मुताबिक काम न करने वाले व्यवहार को ठीक करने के लिए कुछ कार्रवाइयां करनी पड़ सकती हैं.
- हमारा सुझाव है कि सीओआरएस हेडर सेट करने के लिए,
<Add>के बजाय<Set>का इस्तेमाल करें. इसके बारे में यहां बताया गया है.<Add>का इस्तेमाल करते समय, अगरAccess-Control-Allow-Originहेडर पहले से मौजूद है, तो आपको यह गड़बड़ी दिखेगी:The 'Access-Control-Allow-Origin' header contains multiple values '*, *', but only one is allowed.ज़्यादा जानकारी के लिए, सीओआरएस से जुड़ी गड़बड़ी : हेडर में कई वैल्यू '*, *' मौजूद हैं, लेकिन सिर्फ़ एक वैल्यू की अनुमति है लेख पढ़ें.
<AssignMessage async="false" continueOnError="false" enabled="true" name="add-cors"> <DisplayName>Add CORS</DisplayName> <FaultRules/> <Properties/> <Set> <Headers> <Header name="Access-Control-Allow-Origin">{request.header.origin}</Header> <Header name="Access-Control-Allow-Headers">origin, x-requested-with, accept, content-type, authorization</Header> <Header name="Access-Control-Max-Age">3628800</Header> <Header name="Access-Control-Allow-Methods">GET, PUT, POST, DELETE</Header> </Headers> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="response"/> </AssignMessage>
मौजूदा प्रॉक्सी में सीओआरएस हेडर जोड़ना
आपको मैन्युअल तरीके से, 'मैसेज असाइन करें' से जुड़ी नई नीति बनानी होगी. साथ ही, पिछले सेक्शन में दी गई 'CORS जोड़ें' नीति का कोड कॉपी करके इसमें डालना होगा. इसके बाद, नीति को एपीआई प्रॉक्सी के TargetEndpoint के रिस्पॉन्स प्रीफ़्लो से अटैच करें. हेडर की वैल्यू में, ज़रूरत के हिसाब से बदलाव किया जा सकता है. नीतियां बनाने और उन्हें अटैच करने के बारे में ज़्यादा जानकारी के लिए, नीति क्या होती है? लेख पढ़ें.
सीओआरएस प्रीफ़्लाइट अनुरोधों को मैनेज करना
सीओआरएस प्रीफ़्लाइट का मतलब है कि किसी सर्वर को यह पुष्टि करने के लिए अनुरोध भेजना कि वह सीओआरएस के साथ काम करता है या नहीं. प्रीफ़्लाइट रिस्पॉन्स में आम तौर पर यह जानकारी शामिल होती है: सर्वर किन ऑरिजिन से सीओआरएस अनुरोध स्वीकार करेगा, सीओआरएस अनुरोधों के लिए काम करने वाले एचटीटीपी तरीकों की सूची, संसाधन के अनुरोध के हिस्से के तौर पर इस्तेमाल किए जा सकने वाले हेडर, प्रीफ़्लाइट रिस्पॉन्स को ज़्यादा से ज़्यादा कितने समय तक कैश मेमोरी में सेव किया जाएगा वगैरह. अगर सेवा, सीओआरएस के साथ काम नहीं करती है या क्लाइंट के ऑरिजिन से क्रॉस-ऑरिजिन अनुरोध स्वीकार नहीं करना चाहती है, तो ब्राउज़र की क्रॉस-ऑरिजिन नीति लागू की जाएगी. साथ ही, क्लाइंट से किए गए किसी भी क्रॉस-डोमेन अनुरोध को अस्वीकार कर दिया जाएगा. ये अनुरोध, उस सर्वर पर होस्ट किए गए संसाधनों के साथ इंटरैक्ट करने के लिए किए जाते हैं.
आम तौर पर, सीओआरएस प्रीफ़्लाइट अनुरोध, एचटीटीपी OPTIONS तरीके से किए जाते हैं. जब सीओआरएस के साथ काम करने वाले किसी सर्वर को OPTIONS अनुरोध मिलता है, तो वह क्लाइंट को सीओआरएस हेडर का एक सेट भेजता है. इससे पता चलता है कि सर्वर, सीओआरएस के साथ किस लेवल पर काम करता है. इस हैंडशेक के बाद, क्लाइंट को पता चल जाता है कि उसे नॉन-ऑरिजिन डोमेन से किस तरह का अनुरोध करने की अनुमति है.
प्रीफ़्लाइट के बारे में ज़्यादा जानकारी के लिए, क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग के लिए W3C का सुझाव देखें. इसके अलावा, सीओआरएस पर कई ब्लॉग और लेख उपलब्ध हैं. इन्हें भी पढ़ा जा सकता है.
Apigee में, सीओआरएस प्रीफ़्लाइट का समाधान डिफ़ॉल्ट रूप से शामिल नहीं होता. हालांकि, इसे लागू किया जा सकता है. इसके बारे में इस सेक्शन में बताया गया है. इस कुकी का मकसद, प्रॉक्सी को किसी शर्त वाले फ़्लो में OPTIONS अनुरोध का आकलन करने की अनुमति देना है. इसके बाद, प्रॉक्सी क्लाइंट को सही जवाब भेज सकता है.
आइए, एक सैंपल फ़्लो देखें. इसके बाद, उन हिस्सों पर चर्चा करें जो प्रीफ़्लाइट अनुरोध को हैंडल करते हैं:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ProxyEndpoint name="default">
<Description/>
<Flows>
<Flow name="OptionsPreFlight">
<Request/>
<Response>
<Step>
<Name>add-cors</Name>
</Step>
</Response>
<Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition>
</Flow>
</Flows>
<PreFlow name="PreFlow">
<Request/>
<Response/>
</PreFlow>
<HTTPProxyConnection>
<BasePath>/v1/cnc</BasePath>
<VirtualHost>default</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
<RouteRule name="NoRoute">
<Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition>
</RouteRule>
<RouteRule name="default">
<TargetEndpoint>default</TargetEndpoint>
</RouteRule>
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
</ProxyEndpoint>इस ProxyEndpoint के मुख्य हिस्से यहां दिए गए हैं:
- OPTIONS अनुरोध के लिए, शर्त के साथ NULL टारगेट के लिए RouteRule बनाया जाता है. ध्यान दें कि
कोई TargetEndpoint तय नहीं किया गया है. अगर OPTIONS अनुरोध मिलता है और Origin और Access-Control-Request-Method अनुरोध हेडर शून्य नहीं हैं, तो प्रॉक्सी तुरंत क्लाइंट को जवाब में सीओआरएस हेडर भेजता है. ऐसा करके, वह "बैकएंड" के डिफ़ॉल्ट टारगेट को बायपास कर देता है.
फ़्लो की शर्तों और RouteRule के बारे में ज़्यादा जानने के लिए, फ़्लो वैरिएबल के साथ शर्तें लेख पढ़ें.
<RouteRule name="NoRoute"> <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition> </RouteRule> - एक OptionsPreFlight फ़्लो बनाया जाता है. अगर कोई OPTIONS अनुरोध मिलता है और Origin और Access-Control-Request-Method अनुरोध हेडर शून्य नहीं हैं, तो यह फ़्लो में एक Add CORS नीति जोड़ता है. इसमें सीओआरएस हेडर शामिल होते हैं.
<Flow name="OptionsPreFlight"> <Request/> <Response> <Step> <Name>add-cors</Name> </Step> </Response> <Condition>request.verb == "OPTIONS" AND request.header.origin != null AND request.header.Access-Control-Request-Method != null</Condition> </Flow>
सीओआरएस के सैंपल समाधान का इस्तेमाल करना
सीओआरएस की समस्या को हल करने के लिए, शेयर किए गए फ़्लो के तौर पर लागू किया गया एक सैंपल GitHub पर उपलब्ध है. शेयर किए गए फ़्लो बंडल को अपने एनवायरमेंट में इंपोर्ट करें. इसके बाद, इसे फ़्लो हुक का इस्तेमाल करके या सीधे तौर पर एपीआई प्रॉक्सी फ़्लो से अटैच करें. ज़्यादा जानकारी के लिए, सैंपल के साथ दी गई CORS-Shared-FLow README फ़ाइल देखें.