Delivery Access Token

DeliveryAccessToken एक रीड-ओनली टोकन है जिसका उपयोग CDA (सार्वजनिक डिलीवरी) से प्रकाशित कंटेंट पढ़ते समय किया जाता है। किसी वेबसाइट या ऐप का ब्राउज़र जब प्रकाशित कंटेंट लाता है, तो इसी टोकन से CDA को कॉल करता है। जारी करते समय इसे एक SpaceRole से बाइंड किया जाता है, और वही भूमिका टोकन का रीड दायरा तय करती है (कौन-से Content Type पढ़े जा सकते हैं)।

CMA में DeliveryAccessToken एक Space की उप-संसाधन है, और इसका पाथ /spaces/{spaceId}/delivery-access-tokens पर आधारित है। यह टोकन ब्राउज़र (क्लाइंट) में उजागर अवस्था में काम करता है, इसलिए जिस भूमिका से इसे बाइंड किया जाए वह केवल आवश्यक Content Type ही पढ़ने वाली न्यूनतम-विशेषाधिकार (least-privilege) भूमिका होनी चाहिए (नीचे सुरक्षा: न्यूनतम-विशेषाधिकार बाइंडिंग देखें)। इसके अलावा allowedReferrers में कॉल के लिए अनुमत origin रख दिए जाएँ, तो निर्दिष्ट साइट के बाहर यह टोकन काम नहीं करता (origin लिखने के नियम तथा Referer की जाँच देखें)।

संसाधन संरचना

नीचे DeliveryAccessToken बनाने पर मिलने वाली प्रतिक्रिया दी गई है। sys (सिस्टम गुण) में टोकन मान और दायरा होता है, और बॉडी में name, description तथा allowedReferrers होते हैं।

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PUFQuOAqWOc",
    "type": "DeliveryAccessToken",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "user": { "sys": { "id": "3trmXRLdJIqc9GPBbyFYQQw6hf9kGj", "type": "Refer", "targetType": "User" } },
    "createdBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PUFQsSPi0nt", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-18T09:24:23.156Z",
    "updatedBy": { "sys": { "id": "3trmXRM3RqbgSnifyg7PUFQsSPi0nt", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-18T09:24:23.156Z",
    "accessToken": "DVRATbQ8mX2vK9pLs7Rf1Zt0Nc4Wd6Hg5Ua2Ee9Ck3PoYx8Bj6Hg5Ua2Ee9Ck3Po…",
    "scopes": ["DELIVERY_ACCESS_TOKEN"]
  },
  "allowedReferrers": ["https://shop.example.com"],
  "description": "कपड़ों की दुकान की सार्वजनिक साइट के लिए केवल-पढ़ने वाला डिलीवरी टोकन",
  "name": "सार्वजनिक वेबसाइट डिलीवरी"
}

मुख्य कुंजियाँ:

• sys.id: DeliveryAccessToken का विशिष्ट पहचानकर्ता। एकल चयन, संपादन और हटाने के पाथ के {deliveryAccessTokenId} में जाता है।
• sys.accessToken: CDA कॉल में उपयोग किया जाने वाला गुप्त टोकन मान। जारी करने के बाद चयन में भी यही मान ज्यों का त्यों आता है, इसलिए उजागर होने को लेकर सावधानी बरतनी चाहिए (नीचे सुरक्षा अनुभाग देखें)।
• sys.scopes: टोकन का अनुमति दायरा। DeliveryAccessToken जारी करते समय हमेशा ["DELIVERY_ACCESS_TOKEN"] होता है।
• sys.user: इस टोकन का अधिकार-धारक समर्पित उपयोगकर्ता। जारी करते समय स्वतः बन जाता है, और बाइंड की गई SpaceRole के अधिकार इसी उपयोगकर्ता को दिए जाते हैं। यानी टोकन का प्रभावी अधिकार इसी उपयोगकर्ता से आता है। यह उस व्यक्ति (sys.createdBy) से भिन्न उपयोगकर्ता है जिसने इस टोकन को वास्तव में जारी किया।
• name: बनाते समय निर्दिष्ट किया गया टोकन नाम (उदाहरण: सार्वजनिक वेबसाइट डिलीवरी)।
• description: टोकन का विवरण (वैकल्पिक)।
• allowedReferrers: यह सूची तय करती है कि इस टोकन को किन origin से कॉल किया जा सकता है। सूची खाली हो, तो कोई पाबंदी नहीं लगती। ऊपर का उदाहरण ऐसा टोकन है जो केवल कपड़ों की दुकान की सार्वजनिक साइट (https://shop.example.com) से कॉल करने पर ही जाँच पार करता है (लिखने के नियम और जाँच का तरीका जानने के लिए origin लिखने के नियम तथा Referer की जाँच देखें)।

ऊपर के उदाहरण में accessToken एक गुप्त मान है, इसलिए इसे उदाहरण स्ट्रिंग से बदल दिया गया है। वास्तव में यह लंबा और अपारदर्शी स्ट्रिंग होता है, और जारी करने के बाद दोबारा चयन करने पर भी वही मान आता है।

सिस्टम गुण (sys)

हर DeliveryAccessToken अपने सामान्य सिस्टम गुण और टोकन-विशिष्ट गुण sys ऑब्जेक्ट में रखता है। space, user, createdBy, updatedBy Refer आकार ({ "sys": { "id", "type": "Refer", "targetType" } }) में आते हैं।

बॉडी गुण:

सुरक्षा: न्यूनतम-विशेषाधिकार बाइंडिंग

DeliveryAccessToken एक ऐसा टोकन है जो ब्राउज़र और आगंतुकों के सामने उजागर अवस्था में CDA को कॉल करता है। इसलिए इसे किस SpaceRole से बाइंड किया जाता है, यही इस टोकन की सुरक्षा सीमा बन जाता है।

• बनाने के अनुरोध के role में केवल आवश्यक Content Type पढ़ने वाली न्यूनतम-विशेषाधिकार SpaceRole की sys.id डालें। सार्वजनिक डिलीवरी के लिए रीड-ओनली भूमिका की अनुशंसा की जाती है।
• Administrator भूमिका को कभी बाइंड न करें। यह टोकन क्लाइंट में उजागर होता है, इसलिए यदि आप प्रबंधन अधिकार वाली भूमिका बाइंड करते हैं तो वे अधिकार ज्यों के त्यों बाहर लीक हो जाते हैं। साथ ही SpaceRole सूची की पहली प्रविष्टि को बिना सोचे-समझे न लें, बल्कि अपनी इच्छित न्यूनतम-विशेषाधिकार भूमिका की sys.id स्पष्ट रूप से निर्दिष्ट करें।
• allowedReferrers से यह भी बाँध दें कि इस टोकन का उपयोग कहाँ किया जा सकता है। बाइंड की गई भूमिका तय करती है कि इस टोकन से क्या पढ़ा जा सकता है, और यह सूची तय करती है कि इसे कहाँ से कॉल किया जा सकता है। ब्राउज़र में चलने वाले टोकन का मान स्वयं छिपाया नहीं जा सकता, इसलिए सार्वजनिक साइट का origin सूची में रख देने पर, टोकन मान बाहर लीक हो जाने पर भी उस साइट के बाहर से की गई CDA कॉल जाँच पार नहीं कर पाती (Referer की जाँच देखें)।
• accessToken एक गुप्त मान है जो जारी करने के बाद भी उसी मान से चयनित होता है। इसे क्लाइंट बिल्ड में सुरक्षित रूप से इंजेक्ट करें, परंतु बाहर ज्यों का त्यों उजागर न करें।

स्थिति और बाधाएं

बनाते और संपादित करते समय पालन किए जाने वाले मान संबंधी प्रतिबंध।

बाइंडिंग और अनुमति से जुड़े नियम:

• बाइंड की जाने वाली role उस Space में वास्तव में मौजूद होनी चाहिए। उस Space में न मौजूद भूमिका की sys.id डालने पर निर्माण अस्वीकार हो जाता है।
• कॉल करने वाला केवल वही भूमिका बाइंड कर सकता है जो उसके पास उस Space में है। यह प्रतिबंध इसलिए है ताकि कोई अपने पास न मौजूद भूमिका बाइंड करके टोकन को अपने से ऊँचा अधिकार न दे सके, और इस प्रतिबंध को तोड़ने वाला निर्माण अनुरोध अस्वीकार हो जाता है। हालाँकि उस Space का प्रशासक (Administrator भूमिका रखने वाला) इस प्रतिबंध से मुक्त है और किसी भी भूमिका को बाइंड कर सकता है।
• DeliveryAccessToken एक ऐसा संसाधन है जिसकी संख्या की सीमा होती है। वर्तमान योजना की जारी-संख्या सीमा पार होने पर निर्माण अस्वीकार हो जाता है। योजना-वार सीमाओं के लिए मूल्य योजनाएं देखें।
• जारी करने और प्रबंधन (बनाना, चयन, संपादन, हटाना) के लिए कॉल करने वाले की भूमिका के settings में SETTING_DELIVERY_ACCESS_TOKEN होना ज़रूरी है। लिखने तक की अनुमति देने वाला Space Access Token जारी करने वाले SETTING_SPACE_ACCESS_TOKEN से यह अलग एक्शन है, इसलिए केवल डिलीवरी टोकन जारी करने की अनुमति देकर लिखने वाले टोकन का जारी होना रोका जा सकता है (SpaceRole देखें)।
• यह API केवल कंसोल लॉगिन सत्र और Personal Access Token से कॉल किया जाता है। जारी किए गए DeliveryAccessToken से खुद कोई दूसरा DeliveryAccessToken नहीं बनाया जा सकता।

origin लिखने के नियम

allowedReferrers की प्रत्येक प्रविष्टि एक स्ट्रिंग है जो कॉल के लिए अनुमत किसी एक origin को दर्शाती है। इसे नीचे दिए स्वरूप में लिखा जाता है।

"allowedReferrers": [
  "https://shop.example.com",
  "https://*.shop.example.com",
  "http://localhost:3000"
]

सूची में अधिकतम 50 प्रविष्टियाँ रखी जा सकती हैं, और एक ही origin को दो बार नहीं डाला जा सकता। प्रत्येक प्रविष्टि को नीचे दिए नियमों का पालन करना होगा।

• स्कीम में केवल https लिखा जाता है। http केवल localhost, 127.0.0.1 और [::1] के लिए अनुमत है।
• वाइल्डकार्ड के रूप में केवल सबसे आगे का एक *. लेबल लिखा जाता है। पाथ में वाइल्डकार्ड नहीं लिखा जा सकता।
• होस्ट ASCII में लिखा जाता है। अंतरराष्ट्रीयकृत डोमेन को प्यूनिकोड रूप में डाला जाता है।
• पोर्ट 1 से 65535 तक होता है। इसे छोड़ देने पर स्कीम का डिफ़ॉल्ट पोर्ट (https के लिए 443, http के लिए 80) माना जाता है।
• प्रविष्टि में पाथ लिखा हो, तो अनुरोध का पाथ उससे पूरी तरह समान होने पर ही अनुरोध जाँच पार करता है। ब्राउज़र पाथ को परसेंट-एन्कोड करके भेजता है, इसलिए पाथ में केवल ASCII लिखा जाता है।
• उपयोगकर्ता जानकारी (user@), क्वेरी (?) या फ़्रैगमेंट (#) से युक्त प्रविष्टि अस्वीकार कर दी जाती है।

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

Referer की जाँच

जारी करने के बाद इस टोकन से CDA कॉल करने पर, हर अनुरोध पर allowedReferrers लागू करके यह तय किया जाता है कि अनुरोध जाँच पार करेगा या नहीं।

• सूची खाली हो, तो कोई पाबंदी नहीं लगती। किसी भी origin से कॉल किया जाए, अनुरोध जाँच पार कर जाता है।
• सूची में एक भी प्रविष्टि हो, तो जाँच अनुरोध के Referer हेडर के मान से की जाती है। Origin हेडर को नहीं देखा जाता।
• Referer हेडर मौजूद न हो या उसका मान खाली हो, तो अनुरोध अस्वीकार कर दिया जाता है। ब्राउज़र यह हेडर स्वयं भेजता है, पर सर्वर पर चलने वाली बिल्ड स्क्रिप्ट या सर्वर रेंडरिंग की तरह जहाँ Referer भेजा नहीं जाता, वहाँ काम आने वाले टोकन की सूची खाली छोड़ दी जाती है।
• जाँच पार करने के लिए Referer की स्कीम, होस्ट और पोर्ट, तीनों सूची की किसी एक प्रविष्टि से समान होने चाहिए। उस प्रविष्टि में पाथ भी हो, तो पाथ भी समान होना चाहिए।
• https://*.shop.example.com में admin.shop.example.com जैसे .shop.example.com पर ख़त्म होने वाले सभी होस्ट शामिल होते हैं, पर shop.example.com स्वयं शामिल नहीं होता। दोनों की अनुमति देनी हो, तो https://shop.example.com को एक और प्रविष्टि के रूप में डालें।
• यह जाँच इस टोकन से भेजे जाने वाले हर अनुरोध पर लगती है। CDA का कोई भी पाथ कॉल किया जाए, यही नियम लागू रहता है।
• जाँच में रुके अनुरोध को HTTP 403 के साथ अस्वीकार कर दिया जाता है। लौटने वाला कोड नीचे त्रुटियाँ में दिया गया है।

त्रुटियाँ

ये कोड DeliveryAccessToken के साथ काम करते समय मिलते हैं। सभी संसाधनों में समान रूप से मिलने वाले कोड के लिए सामान्य त्रुटियाँ देखें।

API

नीचे दिए गए सभी एंडपॉइंट का आधार URL https://cma.weegloo.com/v1 है, और Authorization हेडर में CMA को प्रमाणित करने वाला Bearer टोकन आवश्यक है। DeliveryAccessToken के संपादन तथा आंशिक संपादन के लिए X-Weegloo-Version हेडर आवश्यक नहीं है।

संबंधित दस्तावेज़

• SpaceRole: इस टोकन से बाइंड की जाने वाली भूमिका (रीड दायरा) को परिभाषित करता है।
• CDA अवलोकन: इस टोकन से प्रकाशित कंटेंट पढ़ने वाली डिलीवरी API।
• Space Access Token: एक Space के भीतर लिखने तक की अनुमति देने वाला टोकन (इसमें भी यही origin पाबंदी रहती है)।
• Personal Access Token: सर्वर/CI के लिए Weegloo User टोकन।