ऑपरेटर के दायरे

ऑपरेटर स्कोप यह नियंत्रित करते हैं कि प्रमाणीकरण के बाद कोई Gateway क्लाइंट क्या कर सकता है। वे एक विश्वसनीय Gateway ऑपरेटर डोमेन के भीतर नियंत्रण-प्लेन सुरक्षा-सीमा हैं, शत्रुतापूर्ण बहु-टेनेंट पृथक्करण नहीं। लोगों, टीमों या मशीनों के बीच मजबूत पृथक्करण के लिए, अलग-अलग OS उपयोगकर्ताओं या होस्ट के अंतर्गत अलग-अलग Gateway चलाएँ। संबंधित: सुरक्षा, Gateway प्रोटोकॉल, Gateway पेयरिंग, डिवाइस CLI।

​

भूमिकाएँ

हर Gateway WebSocket क्लाइंट एक भूमिका के साथ कनेक्ट होता है:

• operator: नियंत्रण-प्लेन क्लाइंट, जैसे CLI, नियंत्रण UI, स्वचालन और विश्वसनीय सहायक प्रक्रियाएँ।
• node: क्षमता होस्ट (macOS, iOS, Android, हेडलेस), जो node.invoke के माध्यम से कमांड उपलब्ध कराते हैं।

ऑपरेटर RPC विधियों के लिए operator भूमिका आवश्यक है; Node से आरंभ होने वाली विधियों के लिए node भूमिका आवश्यक है।

​

स्कोप स्तर

अज्ञात भावी operator.* स्कोप के लिए सटीक मिलान आवश्यक है, जब तक कि कॉलर के पास पहले से operator.admin न हो।

​

विधि स्कोप केवल पहला नियंत्रण-बिंदु है

प्रत्येक Gateway RPC में न्यूनतम-विशेषाधिकार वाला विधि स्कोप होता है, जो तय करता है कि कोई अनुरोध उसके हैंडलर तक पहुँचेगा या नहीं। पैरामीटर-संवेदी विधियाँ डिस्पैच से पहले वह स्कोप निर्धारित करती हैं, ताकि प्राधिकरण विफलताओं के लिए एक ही मानक संरचित प्रतिक्रिया हो:

• agent को सामान्य टर्न के लिए operator.write और /new या /reset सत्र जीवनचक्र कमांड के लिए operator.admin चाहिए।
• node.invoke को सामान्य रिले कमांड के लिए operator.write और browser.proxy, fs.listDir तथा terminal.upload के लिए operator.admin चाहिए।
• talk.config को operator.read चाहिए; includeSecrets: true को operator.talk.secrets भी चाहिए।

कुछ हैंडलर अनुमोदित या परिवर्तित की जा रही ठोस वस्तु के आधार पर इसके बाद और कड़े जाँच लागू करते हैं:

• device.pair.approve तक operator.pairing के साथ पहुँचा जा सकता है, लेकिन किसी ऑपरेटर डिवाइस को अनुमोदित करने पर केवल वही स्कोप जारी या बनाए रखे जा सकते हैं, जो कॉलर के पास पहले से हैं।
• node.pair.approve तक operator.pairing के साथ पहुँचा जा सकता है, फिर यह लंबित Node की घोषित कमांड सूची से अतिरिक्त अनुमोदन स्कोप निर्धारित करता है।
• chat.send एक लेखन-स्कोप वाली विधि है, लेकिन /config set और /config unset चैट कमांड के लिए उसके अतिरिक्त operator.admin आवश्यक है, चाहे कॉलर का चैट-भेजने का स्कोप कुछ भी हो।

इससे निम्न-स्कोप वाले ऑपरेटर कम-जोखिम पेयरिंग कार्रवाइयाँ कर सकते हैं और सभी पेयरिंग अनुमोदनों को केवल-एडमिन बनाने की आवश्यकता नहीं पड़ती। सत्र परिवर्तन RPC को उनके समझौता किए गए ऑपरेटर स्कोप द्वारा प्राधिकृत किया जाता है, चाहे कनेक्ट होने वाले क्लाइंट का client.id या client.mode कुछ भी हो। क्लाइंट पहचान अब भी कनेक्शन और डिवाइस-प्रमाणीकरण नीति को प्रभावित कर सकती है, लेकिन वह सत्र परिवर्तन प्राधिकार न तो प्रदान करती है और न हटाती है।

​

डिवाइस पेयरिंग अनुमोदन

डिवाइस पेयरिंग रिकॉर्ड अनुमोदित भूमिकाओं और स्कोप का स्थायी स्रोत हैं। पहले से पेयर किए गए डिवाइस को बिना सूचना के अधिक व्यापक पहुँच नहीं मिलती: अधिक व्यापक भूमिका या स्कोप माँगने वाला पुनः कनेक्शन एक नया लंबित अपग्रेड अनुरोध बनाता है। डिवाइस अनुरोध का अनुमोदन:

• ऑपरेटर भूमिका के बिना अनुरोध को ऑपरेटर स्कोप अनुमोदन की आवश्यकता नहीं होती।
• गैर-ऑपरेटर डिवाइस भूमिका (उदाहरण के लिए node) के अनुरोध के लिए operator.admin आवश्यक है, भले ही device.pair.approve को स्वयं केवल operator.pairing की आवश्यकता हो।
• operator.read, operator.write, operator.approvals, operator.questions, operator.pairing या operator.talk.secrets के अनुरोध के लिए कॉलर के पास वह स्कोप या operator.admin पहले से होना आवश्यक है।
• operator.admin के अनुरोध के लिए operator.admin आवश्यक है।
• स्पष्ट स्कोप के बिना सुधार अनुरोध मौजूदा ऑपरेटर टोकन के स्कोप प्राप्त कर सकता है; यदि उस टोकन में एडमिन स्कोप है, तो अनुमोदन के लिए फिर भी operator.admin आवश्यक है।

गैर-एडमिन साझा-रहस्य और विश्वसनीय-प्रॉक्सी सत्र केवल अपने घोषित ऑपरेटर स्कोप के भीतर ऑपरेटर-डिवाइस अनुरोध अनुमोदित कर सकते हैं; गैर-ऑपरेटर भूमिकाओं का अनुमोदन केवल एडमिन कर सकता है, भले ही वे सत्र अन्यथा operator.pairing का उपयोग कर सकते हों। पेयर किए गए डिवाइस टोकन सत्रों के लिए, प्रबंधन स्वयं तक सीमित होता है, जब तक कि कॉलर के पास operator.admin न हो: गैर-एडमिन कॉलर केवल अपनी पेयरिंग प्रविष्टियाँ देखता है और केवल अपनी डिवाइस प्रविष्टि को अनुमोदित, अस्वीकार, रोटेट, निरस्त या हटा सकता है।

​

Node पेयरिंग अनुमोदन

पुरानी node.pair.* विधियाँ Gateway के स्वामित्व वाले एक अलग Node पेयरिंग स्टोर का उपयोग करती हैं। WS Node इसके बजाय डिवाइस पेयरिंग (role: node) का उपयोग करते हैं, लेकिन वही अनुमोदन शब्दावली लागू होती है। दोनों स्टोर के संबंध के लिए Gateway पेयरिंग देखें। node.pair.approve लंबित अनुरोध की कमांड सूची से अतिरिक्त आवश्यक स्कोप निर्धारित करता है: किसी Node घोषणा को अनुमोदित करने से वे कमांड सक्षम नहीं होते जिनका अलग रनटाइम अनुमति-सूची नियंत्रण-बिंदु है। उदाहरण के लिए, computer.act घोषित करने वाले Node को अनुमोदित करने के लिए पेयरिंग और लेखन स्कोप आवश्यक हैं, लेकिन यह केवल सतह को दर्ज करता है। किसी एडमिनिस्ट्रेटर या स्वामी को अब भी computer.act को सक्रिय करना होगा। इसके सक्रिय रहने के दौरान, node.invoke के माध्यम से इसे चलाने के लिए लेखन स्कोप आवश्यक है, लेकिन प्रत्येक कार्रवाई के लिए एडमिन स्कोप आवश्यक नहीं है। Node पेयरिंग पहचान और विश्वास स्थापित करती है; यह किसी Node की अपनी system.run Exec अनुमोदन नीति को प्रतिस्थापित नहीं करती।

​

साझा-रहस्य प्रमाणीकरण

साझा Gateway टोकन/पासवर्ड प्रमाणीकरण को उस Gateway के लिए विश्वसनीय ऑपरेटर पहुँच माना जाता है। OpenAI-संगत HTTP सतहें, /tools/invoke और HTTP सत्र-इतिहास एंडपॉइंट साझा-रहस्य बेयरर प्रमाणीकरण के लिए पूर्ण डिफ़ॉल्ट ऑपरेटर स्कोप समूह पुनर्स्थापित करते हैं, भले ही कॉलर अधिक सीमित घोषित स्कोप भेजे। पहचान-युक्त मोड, जैसे विश्वसनीय प्रॉक्सी प्रमाणीकरण या निजी-इनग्रेस none, अब भी स्पष्ट घोषित स्कोप का पालन कर सकते हैं। वास्तविक विश्वास-सीमा पृथक्करण के लिए अलग-अलग Gateway का उपयोग करें।