Space Access Token

Space Access Token एक ऐसा टोकन है जिससे किसी एक Space के भीतर कंटेंट पढ़ा और लिखा जा सकता है। CMA से कंटेंट बनाया, संपादित और हटाया जा सकता है, और CDA रीड तथा Upload भी इसी टोकन से कॉल किए जाते हैं। जारी करते समय इसे एक SpaceRole से बाइंड किया जाता है, और वही भूमिका तय करती है कि टोकन क्या और कहाँ तक कर सकता है (किस Content Type को किस क्रिया से संभाल सकता है)।

केवल-पढ़ने वाली Delivery Access Token के विपरीत यह टोकन लिखने तक की अनुमति देता है। दूसरी ओर, पूरे उपयोगकर्ता खाते से बंधी Personal Access Token के विपरीत यह केवल एक Space तक सीमित रहता है, और Space सेटिंग, संगठन व खाते के तल या किसी दूसरी Space तक इसकी पहुँच नहीं होती। CMA में Space Access Token एक Space की उप-संसाधन है, और इसका पाथ /spaces/{spaceId}/space-access-tokens पर आधारित है। इस टोकन को सर्वर में रखना है या किसी उजागर क्लाइंट (जैसे अनाम पोस्टिंग) में, यह सेवा के अनुसार तय किया जाता है। यह लिखने के अधिकार वाला ताकतवर टोकन है, इसलिए बाइंड की जाने वाली भूमिका को उस जगह के उजागर दायरे के अनुसार सीमित करके सुरक्षा सुनिश्चित की जाती है जहाँ वह टोकन रखा जाता है (नीचे सुरक्षा: उजागर दायरे के अनुसार भूमिका बाइंडिंग देखें)।

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

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

{
  "sys": {
    "id": "7WpR4mKq2bTnXfLc8Vd3HsJ9gEyAo",
    "type": "SpaceAccessToken",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "user": { "sys": { "id": "3trmXRLdJIqc9GPBbyFYQQwYT32LnU", "type": "Refer", "targetType": "User" } },
    "createdBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-19T02:15:38.472Z",
    "updatedBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-19T02:15:38.472Z",
    "accessToken": "SPCATq8Lm2vK9pXfR1Zt0Nc4Wd6Hg5Ua2Ee9Ck3PoYx8Bj6Hg5Ua2Ee9Ck3Po…",
    "scopes": ["SPACE_ACCESS_TOKEN"]
  },
  "description": "कपड़ों की दुकान के शॉपिंग मॉल में उत्पाद दर्ज व संपादित करने के लिए सर्वर टोकन",
  "name": "उत्पाद बैकएंड सर्वर"
}

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

• sys.id: Space Access Token का विशिष्ट पहचानकर्ता। एकल चयन, संपादन और हटाने के पाथ के {spaceAccessTokenId} में जाता है।
• sys.space: वह Space जिससे यह टोकन संबद्ध है। टोकन केवल इसी एक Space में काम करता है।
• sys.accessToken: API कॉल में उपयोग किया जाने वाला गुप्त टोकन मान। यह SPCAT से शुरू होता है, और जारी करने के बाद चयन में भी यही मान ज्यों का त्यों आता है, इसलिए उजागर होने को लेकर सावधानी बरतनी चाहिए (नीचे सुरक्षा अनुभाग देखें)।
• sys.scopes: टोकन का अनुमति दायरा। Space Access Token जारी करते समय हमेशा ["SPACE_ACCESS_TOKEN"] होता है।
• sys.user: इस टोकन का अधिकार-धारक समर्पित उपयोगकर्ता। जारी करते समय स्वतः बन जाता है, और बाइंड की गई SpaceRole के अधिकार इसी उपयोगकर्ता को दिए जाते हैं। यानी टोकन का प्रभावी अधिकार इसी उपयोगकर्ता से आता है। यह उस व्यक्ति (sys.createdBy) से भिन्न उपयोगकर्ता है जिसने इस टोकन को वास्तव में जारी किया।
• name: बनाते समय निर्दिष्ट किया गया टोकन नाम (उदाहरण: उत्पाद बैकएंड सर्वर)।
• description: टोकन का विवरण (वैकल्पिक)।

role (बाइंड की जाने वाली SpaceRole) केवल निर्माण अनुरोध की बॉडी में भेजा जाने वाला इनपुट मान है, और प्रतिक्रिया संसाधन में शामिल नहीं होता। बाइंड की गई भूमिका इस टोकन के लिए बने एक समर्पित उपयोगकर्ता (प्रतिक्रिया का sys.user) को दी जाती है, इसलिए वह चयन प्रतिक्रिया में role फ़ील्ड के रूप में वापस नहीं आती। ऊपर के उदाहरण में accessToken एक गुप्त मान है, इसलिए इसे उदाहरण स्ट्रिंग से बदल दिया गया है। वास्तव में यह SPCAT से शुरू होने वाला लंबा और अपारदर्शी स्ट्रिंग होता है, और जारी करने के बाद दोबारा चयन करने पर भी वही मान आता है।

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

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

बॉडी गुण:

निर्माण अनुरोध की बॉडी के लिए विशेष इनपुट:

सुरक्षा: उजागर दायरे के अनुसार भूमिका बाइंडिंग

Space Access Token लिखने तक की अनुमति देने वाला ताकतवर टोकन है। इसे किस SpaceRole से बाइंड किया जाता है, यही इस टोकन के कर सकने वाले कामों की सीमा और साथ ही इसकी सुरक्षा सीमा बन जाती है। इस टोकन को सर्वर में रखना है या किसी उजागर क्लाइंट (जैसे अनाम पोस्टिंग) में, यह सेवा के अनुसार तय किया जाता है, और सुरक्षा "कहाँ छिपाया जाए" से नहीं, बल्कि बाइंड की गई भूमिका को उजागर दायरे के अनुसार सीमित करने से मिलती है।

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

(स्रोत: weegloo-space-access-token, weegloo-delivery-access-token स्किल, .claude/rules/weegloo-global-rules.md।)

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

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

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

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

API

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

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

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