CORS टेस्टर

सर्वर सहायता वेब

जाँचें कि कोई API किसी ख़ास origin, मेथड और हेडर की अनुमति देता है या नहीं। टूल एक सुरक्षित सर्वर-साइड चेकर से OPTIONS और असली रिक्वेस्ट भेजता है और बताता है कि ब्राउज़र उस कॉल को क्यों अनुमति देगा या रोकेगा।

गोपनीयता: जहाँ संभव हो प्रोसेसिंग आपके ब्राउज़र में होती है। नेटवर्क जाँच मुत्क़न बैकएंड के माध्यम से की जाती है और संग्रहीत नहीं की जाती।

CORS टेस्टर कैसे इस्तेमाल करें

  1. सार्वजनिक API का URL और उस वेब ऐप का origin डालें जो उसे कॉल करेगा।
  2. मेथड चुनें और वे रिक्वेस्ट हेडर सूचीबद्ध करें जो ऐप भेजेगा (Authorization, Content-Type…)।
  3. टेस्ट चलाएँ और फ़ैसला पढ़ें; "Why" सूची ठीक उसी हेडर का नाम बताती है जिसकी वजह से ब्राउज़र रोकेगा।
  4. सर्वर कॉन्फ़िगरेशन ठीक करें और तब तक दोबारा चलाएँ जब तक फ़ैसला Allowed न हो जाए।

CORS टेस्टर की खूबियाँ

  • आपके चुने हुए Origin, मेथड और रिक्वेस्ट हेडर के साथ preflight (OPTIONS) तथा असली रिक्वेस्ट दोनों भेजता है
  • फ़ैसला क़दम-दर-क़दम समझाया जाता है: origin का मिलान, credentials, अनुमत मेथड और हेडर, preflight स्टेटस, max-age
  • CORS-safelisted नियमों से पहचानता है कि preflight ज़रूरी है या नहीं
  • preflight और असली रिस्पॉन्स के हेडर की व्याख्या सहित तालिकाएँ
  • credentials के साथ wildcard, Vary: Origin का न होना और "null" origin पर चेतावनी

CORS टेस्टर का उदाहरण

credentials वाली POST रिक्वेस्ट टेस्ट करना

इनपुट:

URL: https://api.example.com/v1/orders · Origin: https://app.example.com · Method: POST · Headers: Authorization, Content-Type

आउटपुट:

Result: Blocked
Preflight needed: Yes (OPTIONS) · Preflight status: 204
Access-Control-Allow-Origin is "*" but the request is credentialed; browsers reject the wildcard with credentials.
Access-Control-Allow-Headers does not list: Authorization.

CORS टेस्टर के बारे में अक्सर पूछे जाने वाले सवाल

ब्राउज़र preflight कब भेजता है?

GET, HEAD या POST के अलावा किसी भी मेथड के लिए, CORS-safelisted सेट से बाहर के रिक्वेस्ट हेडर के लिए (Accept, Accept-Language, Content-Language और form/text वैल्यू वाला Content-Type सुरक्षित माने जाते हैं) और application/json जैसी Content-Type वैल्यू के लिए। टूल बता देता है कि आपके संयोजन से OPTIONS ट्रिगर होगा या नहीं।

Access-Control-Allow-Origin * होने पर भी मेरी रिक्वेस्ट क्यों रुक रही है?

जब रिक्वेस्ट credentials इस्तेमाल करती है (कुकी या credentials: "include" के साथ Authorization), तब wildcard अस्वीकार कर दिया जाता है। इसके बजाय ठीक वही origin लौटाएँ और Access-Control-Allow-Credentials: true तथा Vary: Origin जोड़ें।

टूल API को मेरे ब्राउज़र के बजाय सर्वर से क्यों कॉल करता है?

ब्राउज़र रुकी हुई रिक्वेस्ट का रिस्पॉन्स छिपा देता है, इसलिए आपको सिर्फ़ एक सामान्य एरर दिखता। रिले आपके चुने हुए Origin हेडर के साथ OPTIONS और असली रिक्वेस्ट भेजता है तथा कच्चे Access-Control-* हेडर लौटाता है, ताकि फ़ैसले की हर वजह समझाई जा सके।

क्या मैं localhost या कोई आंतरिक API टेस्ट कर सकता हूँ?

नहीं। सुरक्षा के लिए रिले निजी, loopback और link-local पतों को मना कर देता है। टेस्ट करने के लिए API को किसी tunnel या सार्वजनिक staging होस्ट के ज़रिए उपलब्ध कराएँ।

तकनीकी नोट्स

रिले Fetch Standard के ब्राउज़र एल्गोरिद्म की नक़ल करता है: preflight Access-Control-Request-Method और Access-Control-Request-Headers के साथ भेजा जाता है तथा असली रिक्वेस्ट Origin हेडर के साथ। सर्वर-साइड फ़ैसले को लोकल पुनर्मूल्यांकन के साथ मिलाया जाता है, ताकि हर वजह साफ़-साफ़ लिखी जा सके — उन मामलों सहित जिन्हें रिले अनुमत मानता है पर जो credentials वाली रिक्वेस्ट में फेल हो जाते हैं।