API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) · पाठ

क्रॉस-ओरिजिन संसाधन साझाकरण (CORS)

अपने API के लिए सुरक्षित क्रॉस-डोमेन अनुरोध सक्षम करने हेतु Nginx में CORS नीतियाँ लागू कीजिए।

पाठ 2, कुल 4 में से12 चरण

क्रॉस-ओरिजिन संसाधन साझाकरण (CORS), CoddyKit पर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

CORS क्या है

कल्पना कीजिए कि आप एक वेब अनुप्रयोग बना रहे हैं। आपका फ्रंटएंड (जैसे React ऐप) app.example.com पर चलता है, लेकिन उसे api.example.com पर चल रहे आपके API से डेटा प्राप्त करना है।

यहीं क्रॉस-ओरिजिन रिसोर्स शेयरिंग (CORS) काम आता है। यह वेब ब्राउज़र द्वारा लागू की गई एक सुरक्षा सुविधा है, जो नियंत्रित करती है कि एक ओरिजिन के वेब पेज दूसरे ओरिजिन से संसाधनों का अनुरोध कैसे कर सकते हैं।

समान-ओरिजिन नीति

CORS, ब्राउज़र की समान-ओरिजिन नीति को कुछ हद तक शिथिल करता है। यह नीति एक महत्वपूर्ण सुरक्षा तंत्र है, जो किसी दुर्भावनापूर्ण वेबसाइट को दूसरी साइट से संवेदनशील डेटा पढ़ने से रोकती है।

ओरिजिन प्रोटोकॉल, होस्ट और पोर्ट से निर्धारित होता है।
https://app.example.com:443, http://app.example.com:80 या https://api.example.com:443 से अलग है।

CORS के बिना, ब्राउज़र आपके फ्रंटएंड को API से बात करने से रोक देंगे, क्योंकि दोनों के ओरिजिन अलग हैं।

CORS कैसे काम करता है

जब आपका ब्राउज़र क्रॉस-ओरिजिन अनुरोध का पता लगाता है, तो वह अनुरोध में एक Origin हेडर जोड़ देता है। इसके बाद सर्वर को विशिष्ट CORS हेडर के साथ उत्तर देना होता है, ताकि ब्राउज़र को पता चले कि अनुरोध की अनुमति है।

सबसे महत्वपूर्ण हेडर Access-Control-Allow-Origin है। यदि यह हेडर सर्वर के उत्तर में मौजूद हो और इसका मान क्लाइंट के ओरिजिन से मेल खाता हो (या * हो), तो ब्राउज़र अनुरोध की अनुमति दे देता है।

सरल और प्रीफ़्लाइट अनुरोध

CORS अनुरोधों को दो प्रकारों में बाँटा जा सकता है:

सरल अनुरोध: ये विशिष्ट सामग्री प्रकारों (जैसे text/plain) वाले सीधे GET, HEAD या POST अनुरोध होते हैं। ब्राउज़र इन्हें तुरंत भेजता है और उत्तर में CORS हेडर की अपेक्षा करता है।
प्रीफ़्लाइट अनुरोध: अधिक जटिल अनुरोधों (जैसे PUT, DELETE, कस्टम हेडर या विशिष्ट सामग्री प्रकार) के लिए ब्राउज़र पहले एक OPTIONS अनुरोध भेजता है। यह 'प्रीफ़्लाइट' सर्वर से जाँच करता है कि वास्तविक अनुरोध भेजना सुरक्षित है या नहीं।

CORS हेडर के लिए Nginx

चूँकि Nginx अक्सर रिवर्स प्रॉक्सी या API गेटवे के रूप में काम करता है, इसलिए यह आपकी बैकएंड सेवाओं के लिए CORS हेडर प्रबंधित करने का उपयुक्त स्थान है। हम उत्तरों में आवश्यक Access-Control-* हेडर जोड़ने के लिए Nginx निर्देशों का उपयोग कर सकते हैं।

इसके लिए मुख्य निर्देश add_header है, जो हमें Nginx के उत्तरों में कस्टम HTTP हेडर जोड़ने की अनुमति देता है।

Allow-Origin कॉन्फ़िगर करना

आइए Nginx को इस तरह कॉन्फ़िगर करें कि वह आपके API पर किसी विशिष्ट ओरिजिन, https://app.example.com, से आने वाले अनुरोधों की अनुमति दे।

हम आपके API अनुरोधों को संभालने वाले location ब्लॉक के भीतर Access-Control-Allow-Origin हेडर जोड़ेंगे।

server {
  listen 80;
  server_name api.example.com;

  location /api/ {
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
    proxy_pass http://backend_api_service;
  }
}

एकाधिक ओरिजिन संभालना

यदि आपके पास कई फ्रंटएंड हैं जिन्हें आपके API तक पहुँच चाहिए, तो क्या होगा? आप Access-Control-Allow-Origin में सीधे कई ओरिजिन सूचीबद्ध नहीं कर सकते। इसके बजाय, आने वाले Origin हेडर के आधार पर हेडर को गतिशील रूप से सेट करने के लिए Nginx के map निर्देश का उपयोग कर सकते हैं।

http {
  map $http_origin $cors_origin {
    default "";
    "https://app.example.com" "https://app.example.com";
    "https://dev.example.com" "https://dev.example.com";
  }

  server {
    listen 80;
    server_name api.example.com;

    location /api/ {
      if ($cors_origin ~ ".") {
        add_header 'Access-Control-Allow-Origin' $cors_origin;
      }
      proxy_pass http://backend_api_service;
    }
  }
}

प्रीफ़्लाइट अनुरोध कॉन्फ़िगर करना

प्रीफ़्लाइट (OPTIONS) अनुरोधों के लिए, ब्राउज़र अपने OPTIONS कॉल के उत्तर में विशिष्ट हेडर की अपेक्षा करता है। Nginx को इन अनुरोधों को बीच में रोककर उपयुक्त CORS हेडर के साथ उत्तर देना होता है, और अक्सर इन्हें बैकएंड पर प्रॉक्सी करने की आवश्यकता नहीं होती।

server {
  listen 80;
  server_name api.example.com;

  location /api/ {
    # Handle preflight OPTIONS requests
    if ($request_method = 'OPTIONS') {
      add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
      add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
      add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
      add_header 'Access-Control-Max-Age' 1728000;
      add_header 'Content-Type' 'text/plain charset=UTF-8';
      add_header 'Content-Length' 0;
      return 204;
    }

    # For actual requests
    add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
    proxy_pass http://backend_api_service;
  }
}

आवश्यक CORS हेडर

Access-Control-Allow-Origin के अलावा, पूर्ण CORS समर्थन के लिए ये हेडर महत्वपूर्ण हैं:

Access-Control-Allow-Methods: अनुमत HTTP विधियाँ निर्दिष्ट करता है (जैसे, GET, POST, PUT)।
Access-Control-Allow-Headers: उन हेडर की सूची देता है जिन्हें क्लाइंट भेज सकता है (जैसे, Content-Type, Authorization)।
Access-Control-Allow-Credentials: यदि क्लाइंट कुकी या HTTP प्रमाणीकरण भेज सकता है, तो इसे true पर सेट करें।
Access-Control-Max-Age: ब्राउज़र प्रीफ़्लाइट प्रतिक्रिया को कितनी देर तक कैश कर सकता है (सेकंड में)।

व्यापक CORS सेटअप

यहाँ Nginx कॉन्फ़िगरेशन का एक अधिक पूर्ण अंश दिया गया है, जो साधारण और प्रीफ़्लाइट, दोनों CORS अनुरोधों को संभालता है और किसी विशिष्ट मूल-स्रोत को आपके API के साथ, क्रेडेंशियल भेजने सहित, इंटरैक्ट करने देता है।

server {
  listen 80;
  server_name api.example.com;

  location /api/ {
    set $cors_origin "https://app.example.com"; # Or use map directive

    if ($request_method = 'OPTIONS') {
      add_header 'Access-Control-Allow-Origin' "$cors_origin";
      add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
      add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';
      add_header 'Access-Control-Allow-Credentials' 'true';
      add_header 'Access-Control-Max-Age' 1728000;
      add_header 'Content-Type' 'text/plain charset=UTF-8';
      add_header 'Content-Length' 0;
      return 204;
    }

    add_header 'Access-Control-Allow-Origin' "$cors_origin";
    add_header 'Access-Control-Allow-Credentials' 'true';
    add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS';
    add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization';

    proxy_pass http://backend_api_service;
  }
}

CORS हेडर जाँच

निम्नलिखित में से कौन-से हेडर Nginx के लिए CORS प्रीफ़्लाइट (OPTIONS) अनुरोध का सही उत्तर देने हेतु आवश्यक हैं?

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावृत्ति: Nginx CORS

इस पाठ में आपने Cross-Origin Resource Sharing (CORS) और सुरक्षित वेब अनुप्रयोगों के लिए इसके महत्वपूर्ण होने का कारण सीखा। हमने इन विषयों को शामिल किया:

Same-Origin Policy और CORS के अस्तित्व का कारण।
साधारण और प्रीफ़्लाइट अनुरोधों के बीच अंतर।
CORS को प्रबंधित करने के लिए add_header और map निर्देशों का उपयोग करके Nginx को कॉन्फ़िगर करना।
Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers और Access-Control-Max-Age जैसे प्रमुख CORS हेडर।

Nginx में CORS को सही ढंग से कॉन्फ़िगर करने से आपके फ्रंटएंड अनुप्रयोग विभिन्न डोमेन पर मौजूद बैकएंड API के साथ सुरक्षित रूप से संचार कर पाते हैं।

शुरुआत निःशुल्क

एआई शिक्षक के साथ API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 12
पाठ: 48

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “क्रॉस-ओरिजिन संसाधन साझाकरण (CORS)” पाठ निःशुल्क है?

हाँ—“क्रॉस-ओरिजिन संसाधन साझाकरण (CORS)” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“क्रॉस-ओरिजिन संसाधन साझाकरण (CORS)” में मैं क्या सीखूँगा?

अपने API के लिए सुरक्षित क्रॉस-डोमेन अनुरोध सक्षम करने हेतु Nginx में CORS नीतियाँ लागू कीजिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।

“क्रॉस-ओरिजिन संसाधन साझाकरण (CORS)” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

← API गेटवे और रिवर्स प्रॉक्सी (Nginx + Spring Cloud Gateway) पर वापस जाएँ