SpaceRole
SpaceRole किसी Space के सदस्यों को दिए जाने वाले अनुमतियों का समूह है। यह एक ही संसाधन में रखता है कि Content Type, Content और Media पर क्या (पढ़ना, बनाना, संपादित करना, हटाना, publish करना) किया जा सकता है, Script को निष्पादित और प्रबंधित किया जा सकता है या नहीं, और Space सेटिंग्स तक पहुँच है या नहीं। केवल किसी खास Content Type तक, या केवल स्वयं द्वारा बनाई गई चीज़ों तक जैसे अनुमति के दायरे को सीमित करने वाले फ़िल्टर भी SpaceRole के भीतर ही तय होते हैं।
बनाया गया SpaceRole अपने आप में किसी पर भी लागू नहीं होता। इसे सदस्य को देने के लिए Space Membership के roles में इस SpaceRole का Refer डाला जाता है। एक सदस्य एक साथ कई SpaceRole रख सकता है। साथ ही DeliveryAccessToken भी किसी एक least-privilege (न्यूनतम अनुमति) SpaceRole से बँधा होता है, और उसी से तय होता है कि उस टोकन से कितना दायरा डिलीवर किया जा सकता है।
संसाधन संरचना
नीचे SpaceRole "उत्पाद केवल-पढ़ने" के एकल पठन (single read) की प्रतिक्रिया है। sys (सिस्टम गुण) के साथ, अनुमति तय करने वाले बॉडी गुण contentType, content, media, settings और script इसमें होते हैं।
{
"sys": {
"id": "3trmXRM3RqbgSnifyg7ObyNrQQbHbm",
"type": "SpaceRole",
"space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
"createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
"createdAt": "2026-06-16T09:53:16.617Z",
"updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
"updatedAt": "2026-06-16T09:53:16.617Z",
"isLocked": false,
"version": 1
},
"name": "उत्पाद केवल-पढ़ने",
"contentType": { "All": { "Allow": [] } },
"content": {
"Read": {
"Allow": [
{ "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
]
}
},
"media": { "All": { "Allow": [] } },
"settings": [],
"script": {}
}मुख्य कुंजियाँ:
contentType: Content Type स्वयं (स्कीमा) पर अनुमति मैप। Content Type को पढ़ने, बनाने, बदलने, हटाने और publish करने की अनुमति को हर एक्शन के अनुसार तय करता है।content: Content (कंटेंट डेटा) पर अनुमति मैप। ऊपर का उदाहरण केवल किसी खास Content Type के Content को ही पढ़ने तक सीमित किया हुआ रूप है।media: Media (फ़ाइल, इमेज) पर अनुमति मैप।script: Script (फ्रंटएंड द्वारा कॉल किए जाने वाले घोषणात्मक (declarative) बैकएंड एंडपॉइंट) पर अनुमति मैप। निष्पादन (Execute) और प्रबंधन (बनाना, पढ़ना, संपादित करना, हटाना) को हर एक्शन के अनुसार तय करता है।settings: Space सेटिंग्स तक पहुँच की अनुमति तय करने वाला स्ट्रिंग सरणी (array)। यह अनुमति मैप नहीं है, इसमें एक्शन के नाम ज्यों के त्यों सूचीबद्ध होते हैं। पूर्ण पहुँच के लिए["SETTING_ALL"], किसी भी सेटिंग तक पहुँच न देने पर[], और ज़रूरत की सेटिंग्स ही चुनकर रखी जा सकती हैं (नीचेsettingsदेखें)।isLocked:trueहोने पर यह Weegloo द्वारा डिफ़ॉल्ट रूप से दी गई भूमिका (जैसे Administrator) है, इसलिए इसे संपादित या हटाया नहीं जा सकता।
सिस्टम गुण (sys)
हर SpaceRole सामान्य सिस्टम गुणों को sys ऑब्जेक्ट में रखता है। space, createdBy, updatedBy Refer रूप ({ "sys": { "id", "type": "Refer", "targetType" } }) में आते हैं।
| गुण | टाइप | विवरण |
|---|---|---|
id | string | संसाधन का अद्वितीय पहचानकर्ता। |
type | string | संसाधन का प्रकार। SpaceRole हमेशा "SpaceRole" होता है। |
space | Refer<Space> | वह Space जिससे यह SpaceRole संबंधित है। |
createdBy | Refer<User> | बनाने वाला उपयोगकर्ता। |
createdAt | string (date-time) | बनाने का समय। |
updatedBy | Refer<User> | अंतिम बार संपादित करने वाला उपयोगकर्ता। |
updatedAt | string (date-time) | अंतिम संपादन का समय। |
isLocked | boolean | true होने पर यह डिफ़ॉल्ट रूप से दी गई भूमिका है, इसलिए इसे संपादित या हटाया नहीं जा सकता। स्वयं बनाई गई भूमिका false होती है। |
version | integer (≥1) | संसाधन संस्करण। हर संपादन पर 1 से बढ़ता है। |
SpaceRole एक सेटिंग संसाधन है जिसमें publish की अवधारणा नहीं है। इसलिए Content और Media के विपरीत sys में publish, archive, status नहीं होते, केवल version होता है। version हर बार SpaceRole संपादित करने पर बढ़ता है।
अनुमति मैप: contentType, content, media
contentType, content, media प्रत्येक एक्शन को कुंजी के रूप में रखने वाले मैप हैं। उपयोग किए जा सकने वाले एक्शन Create (बनाना), Read (पढ़ना), Edit (संपादित करना), Delete (हटाना), Publish (publish करना), Unpublish (publish रद्द करना), Archive (संग्रहण), Unarchive (संग्रहण से बाहर करना) हैं, और सभी एक्शन को एक साथ दर्शाने वाला All भी है। Save नाम का कोई एक्शन नहीं है। संशोधन की अनुमति Edit है, और Save उस घटना का नाम है जिसकी सदस्यता Webhook लेता है। हर एक्शन का मान Allow (अनुमति) और Deny (अस्वीकृति) नियम सरणियों को रखने वाला ऑब्जेक्ट है।
"content": {
"Read": { "Allow": [ /* नियम */ ], "Deny": [ /* नियम */ ] },
"Edit": { "Allow": [ /* नियम */ ] }
}हर नियम (rule) ऑब्जेक्ट में अनुमति के दायरे को सीमित करने वाले वैकल्पिक फ़िल्टर होते हैं।
self: उस नियम के लागू होने के लक्ष्य को संसाधन स्वयं तक सीमित करता है। लक्ष्य संसाधन की ओर इशारा करने वालाReferडाला जाता है।contentTypeमैप में इसका अर्थ किसी एक खास Content Type से है, औरscriptमैप में किसी एक खास Script से।contentType: उसे उस Content Type तक सीमित करता है जिससे वह Content संबंधित है। Content Type की ओर इशारा करने वालाReferडाला जाता है।createdBy: केवल किसी खास उपयोगकर्ता द्वारा बनाए गए संसाधनों तक सीमित करता है।sys.idमें किसी खास उपयोगकर्ता की id डालने पर केवल उसी व्यक्ति द्वारा बनाई गई चीज़ों तक, और आरक्षित मान:selfडालने पर "अभी कॉल करने वाले उपयोगकर्ता द्वारा बनाई गई चीज़ों तक" सीमित होता है।tag: केवल किसी खास Tag वाले संसाधनों तक सीमित करता है।
कौन-सा फ़िल्टर किस अनुमति मैप में अर्थ रखता है, यह तय है। मेल न खाने वाला फ़िल्टर डालने पर भूमिका सहेजना अस्वीकृत हो जाता है। कारण यह है कि चुपचाप अनदेखा कर देने पर वह नियम, जिसे आपने सीमित समझा था, पूरी अनुमति बन जाएगा।
| अनुमति मैप | उपयोग किए जा सकने वाले फ़िल्टर | वे फ़िल्टर जिन्हें डालने पर सहेजना अस्वीकृत होता है |
|---|---|---|
contentType | self (वह Content Type स्वयं)·createdBy | contentType |
content | contentType (वह प्रकार जिससे वह Content संबंधित है)·createdBy·tag | self |
media | createdBy·tag | self |
script | self (वह Script स्वयं)·createdBy | contentType·tag |
contentTypeमैप का लक्ष्यcontentTypeसे नहीं, बल्किselfसे निर्दिष्ट किया जाता है। कारण यह है कि यहाँ Content Type स्वयं को सीमित करने का काम होता है।contentTypeफ़िल्टर का अर्थ "वह प्रकार जिसे यह संसाधन संदर्भित करता है" है, इसलिए वह केवलcontentमैप पर ठीक बैठता है।- जो फ़िल्टर उस संसाधन में मौजूद ही न हो, उस अक्ष से सीमित करने की कोशिश (Content Type पर
tag, Media परcontentType) सहेजने से नहीं रोकी जाती, पर नियम की जाँच इच्छित रूप में नहीं होती। इनका उपयोग न करें।
CDA (डिलीवरी) में
createdByफ़िल्टर (:selfसहित) की जाँच करते समय लक्ष्य Content Type काpublishWithAuthortrueहोना चाहिए। CDA इस फ़िल्टर को publish snapshot केsys.createdByसे जाँचता है, और यदिpublishWithAuthorअपने डिफ़ॉल्ट मानfalseपर है तो snapshot में लेखक नहीं होता, इसलिएAllowनियम किसी से मेल नहीं खाता औरDenyनियम किसी को नहीं छानता। CMA (प्रबंधन) इसे draft केsys.createdByसे जाँचता है, इसलिए यह इस सेटिंग से स्वतंत्र है।publishWithAuthorपूर्वप्रभावी नहीं होता, इसलिए इसे कंटेंट publish करने से पहले चालू करना होता है, और पहले से publish किए गए Content को फिर से publish करना होता है। Content Type केpublishWithAuthorका विवरण देखें।
खाली Allow सरणी [] का अर्थ है उस पूरे प्रकार पर एक्शन की अनुमति। फ़िल्टर खाली होने से छानने को कुछ नहीं रहता, इसलिए सभी संसाधनों पर वह एक्शन खुल जाता है।
खाली Deny सरणी [] उल्टा काम करती है। इसका अर्थ "कुछ भी अस्वीकृत नहीं करना" नहीं, बल्कि उस पूरे प्रकार को अस्वीकृत करके उस एक्शन को पूरी तरह रोक देना है। Allow साथ लिखा हो तो भी वह रुका ही रहता है। अस्वीकृत करने के लिए कुछ नहीं है, इस अर्थ में [] रखने पर यह ठीक उल्टा काम करता है, इसलिए कुछ भी अस्वीकृत न करना हो तो Deny कुंजी ही न डालें।
उदाहरण 1: Administrator (पूर्ण अनुमति, डिफ़ॉल्ट रूप से उपलब्ध)
Administrator भूमिका contentType, content, media, script सभी के All एक्शन को खाली Allow देकर पूरे को अनुमति देती है, और settings में ["SETTING_ALL"] देकर Space सेटिंग्स के पूरे हिस्से तक पहुँचती है। यह भूमिका Weegloo डिफ़ॉल्ट रूप से देता है, इसलिए sys.isLocked true है और इसे संपादित या हटाया नहीं जा सकता।
{
"sys": {
"id": "3trmXRLdJF4GBlAjtcuoWfVubsasp4",
"type": "SpaceRole",
"space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
"createdBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
"createdAt": "2026-06-14T14:56:04.737Z",
"updatedBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
"updatedAt": "2026-06-14T14:56:04.737Z",
"isLocked": true,
"version": 1
},
"name": "Administrator",
"description": "Members of this role have full access to everything in this space.",
"contentType": { "All": { "Allow": [] } },
"content": { "All": { "Allow": [] } },
"media": { "All": { "Allow": [] } },
"settings": ["SETTING_ALL"],
"script": { "All": { "Allow": [] } }
}उदाहरण 2: केवल पठन (केवल किसी खास Content Type पर)
स्वयं बनाई जाने वाली least-privilege भूमिका का उदाहरण। केवल content के Read एक्शन पर नियम रखा गया है, और उस नियम के contentType फ़िल्टर से किसी एक खास Content Type तक सीमित किया गया है। Content Type स्वयं और Media को All को खाली Allow से खोल रखा गया है, पर कंटेंट डेटा में केवल उसी एक प्रकार को पढ़ना संभव है। settings [] होने से Space सेटिंग्स तक पहुँच नहीं है। ऐसी भूमिका को DeliveryAccessToken से बाँधने पर डिलीवरी टोकन केवल उसी दायरे को पढ़ता है। इस भूमिका का JSON ऊपर संसाधन संरचना के "उत्पाद केवल-पढ़ने" जैसा ही है।
settings (Space सेटिंग्स पहुँच)
settings अनुमति मैप नहीं बल्कि एक स्ट्रिंग सरणी है। यह Space सेटिंग्स पर पहुँच की अनुमति रखता है, और इसमें Allow/Deny भी नहीं होते और फ़िल्टर भी नहीं। सरणी में डाली गई एक्शन की अनुमति होती है, और न डाली गई एक्शन की अनुमति नहीं होती।
पूर्ण पहुँच के लिए ["SETTING_ALL"], और कोई पहुँच न देने पर [] रखा जाता है। इन दोनों के बीच का कोई स्तर चाहिए हो, तो नीचे दी गई एक्शन में से चुनकर डाली जाती हैं।
| एक्शन | किन चीज़ों को संभाला जा सकता है |
|---|---|
SETTING_GENERAL | Space स्वयं (नाम, विवरण आदि) |
SETTING_LOCALE | Locale |
SETTING_WEBHOOK | Webhook (कॉल इतिहास और स्थिति सहित) |
SETTING_APP | Market App इंस्टॉल करना |
SETTING_TAG | Tag |
SETTING_DELIVERY_ACCESS_TOKEN | Delivery Access Token |
SETTING_SPACE_ACCESS_TOKEN | Space Access Token |
SETTING_USER | Space Membership (सदस्य नियुक्ति) |
SETTING_ROLE | SpaceRole |
SETTING_WEB_HOSTING | Web Hosting और कस्टम डोमेन |
SETTING_SERVICE_LOGIN | ServiceLogin, ServiceUser, ServiceUserRole |
SETTING_EMAIL_ACCOUNT | मेल भेजने वाला खाता |
SETTING_MONITORING | उपयोग और मेट्रिक्स का पठन |
SETTING_SCHEDULER | Scheduler और उसके निष्पादन रिकॉर्ड |
SETTING_ALL | उपरोक्त सभी |
दोनों प्रकार के टोकन के लिए एक्शन अलग-अलग हैं। केवल SETTING_DELIVERY_ACCESS_TOKEN देने पर केवल-पढ़ने वाला Delivery Access Token जारी किया जा सकता है, पर लिखने तक की क्षमता वाला Space Access Token जारी नहीं किया जा सकता।
settings की एक्शन केवल कंसोल लॉगिन सत्र और Personal Access Token से कॉल की जाती हैं। Space Access Token, Delivery Access Token और ServiceUser टोकन, भूमिका में कोई भी एक्शन डाल रखी हो, इस सूची की API कॉल नहीं कर सकते।
अनुमति मैप (
contentType,content,media,script) की एक्शन सूची, फ़िल्टर कुंजियाँ (self,contentType,createdBy,tag) और:selfका अर्थ, तथा कौन-सा फ़िल्टर किस मैप में मान्य है, ये सब ऊपर अनुमति मैप: contentType, content, media अनुभाग के अनुसार हैं।
script (Script अनुमति)
script Script (फ्रंटएंड द्वारा कॉल किए जाने वाले घोषणात्मक (declarative) बैकएंड एंडपॉइंट) पर अनुमति मैप है। इसकी संरचना content और media जैसी ही है: एक्शन कुंजी के रूप में, और Allow/Deny नियम सरणियाँ मान के रूप में। प्रयुक्त होने वाले एक्शन इस प्रकार हैं:
Create,Read,Edit,Delete: Script संसाधन को बनाते, पढ़ते, संपादित करते और हटाते हैं।Execute: Script को निष्पादित करता है (/executeकॉल)। यह Script की अपनी विशिष्ट एक्शन है।All: उपरोक्त सभी को शामिल करने वाली व्यापक एक्शन है।
चूँकि Script publish किया जाने वाला संसाधन नहीं है, इसलिए Publish/Unpublish जैसी publish एक्शन का उपयोग नहीं होता। नियम फ़िल्टर के रूप में self और createdBy, ये दो उपयोग किए जा सकते हैं।
self: किसी एक खास Script तक सीमित करता है। उस Script की ओर इशारा करने वालाReferडाला जाता है (targetTypeScriptहोता है)।createdBy: बनाने वाले व्यक्ति तक सीमित करता है (:selfसे "केवल स्वयं द्वारा बनाई गई Script")।
contentType और tag ऐसे अक्ष हैं जो Script से नहीं जुड़ते, इसलिए इन्हें डालने पर भूमिका सहेजना अस्वीकृत हो जाता है।
उदाहरण के लिए, सभी Script को निष्पादित करने की अनुमति देते हुए, पर पठन केवल स्वयं द्वारा बनाई गई तक सीमित करने के लिए इस प्रकार लिखें:
"script": {
"Execute": { "Allow": [] },
"Read": {
"Allow": [
{ "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } } }
]
}
}self से सीमित करने पर यह केवल एक Script को निष्पादित कर सकने वाली न्यूनतम अनुमति बन जाती है। भुगतान एजेंसी जैसी बाहरी प्रणाली को निष्पादन की अनुमति देते समय, वह प्रणाली जिस एक खिड़की को बुलाएगी केवल उसे खोलकर बाकी सब बंद रखने का यही तरीका है।
"script": {
"Execute": {
"Allow": [
{ "self": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } } }
]
}
}इस भूमिका को Space Access Token से बाइंड करने पर उस टोकन से केवल निर्दिष्ट एक Script ही निष्पादित होती है। निष्पादन की अनुमति को एक तक सीमित करने का कारण, और यह बात कि Script का निष्पादन लेखक की अनुमति प्रत्यायोजित रूप में पाता है, Script के निष्पादन सिमेंटिक्स, बाधाएँ, सुरक्षा में दी गई है।
यह script अनुमति यह तय करती है कि "Script संसाधन को निष्पादित और प्रबंधित किया जा सकता है या नहीं"। इससे अलग, Script को लिखते (बनाते या संपादित करते) समय, सहेजने के समय लेखक के पास उस Script के statement जिन Content और Media कार्यों को संभालते हैं, उन कार्यों की अनुमति भी वास्तव में होनी चाहिए; अन्यथा सहेजना अस्वीकार कर दिया जाता है (Script की त्रुटियाँ देखें)। विस्तृत जानकारी Script के निष्पादन सिमेंटिक्स, बाधाएँ, सुरक्षा में दी गई है।
त्रुटियाँ
ये कोड SpaceRole के साथ काम करते समय मिलते हैं। सभी संसाधनों में समान रूप से मिलने वाले कोड के लिए सामान्य त्रुटियाँ देखें।
| कोड | शर्त |
|---|---|
WGL400020 | उस अनुमति मैप में अर्थ न रखने वाला फ़िल्टर नियम में डालकर भूमिका सहेजने का प्रयास किया गया। |
API
नीचे दिए गए सभी एंडपॉइंट का बेस URL https://cma.weegloo.com/v1 है, और Authorization हेडर में CMA को प्रमाणित करने वाला Bearer टोकन आवश्यक है। भूमिका संपादन (PUT, PATCH) के लिए ऑप्टिमिस्टिक कंकरेंसी कंट्रोल हेतु X-Weegloo-Version हेडर (वर्तमान संसाधन का sys.version) भी भेजना आवश्यक है। बनाने और हटाने में यह हेडर नहीं होता। sys.isLocked true वाली डिफ़ॉल्ट रूप से उपलब्ध भूमिका को संपादित या हटाया नहीं जा सकता।
संबंधित दस्तावेज़
- Space Membership: सदस्य के
rolesमें SpaceRole को बाँधना। - Delivery Access Token: least-privilege SpaceRole से बँधने वाला डिलीवरी टोकन।
- Content Type: वह Content Type जिसकी ओर अनुमति नियम इशारा करते हैं।
