Gateway

ऑपरेटर स्कोप

ऑपरेटर स्कोप यह परिभाषित करते हैं कि प्रमाणीकरण के बाद कोई Gateway क्लाइंट क्या कर सकता है। वे एक विश्वसनीय Gateway ऑपरेटर डोमेन के भीतर control-plane guardrail हैं, hostile multi-tenant isolation नहीं। यदि आपको लोगों, टीमों या मशीनों के बीच मजबूत अलगाव चाहिए, तो अलग OS users या hosts के अंतर्गत अलग-अलग Gateways चलाएं।

संबंधित: सुरक्षा, Gateway protocol, Gateway pairing, डिवाइस CLI.

भूमिकाएं

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

operator: control-plane क्लाइंट जैसे CLI, Control UI, automation, और विश्वसनीय helper processes.
node: capability hosts जैसे macOS, iOS, Android, या headless nodes जो node.invoke के माध्यम से commands उजागर करते हैं।

Operator RPC methods के लिए operator भूमिका आवश्यक है। Node-originated methods के लिए node भूमिका आवश्यक है।

स्कोप स्तर

स्कोप	अर्थ
`operator.read`	केवल-पठन status, lists, catalog, logs, session reads, और अन्य non-mutating control-plane calls.
`operator.write`	सामान्य mutating operator actions जैसे messages भेजना, tools invoke करना, talk/voice settings अपडेट करना, और node command relay. `operator.read` को भी संतुष्ट करता है।
`operator.admin`	प्रशासनिक control-plane access. हर `operator.*` scope को संतुष्ट करता है। config mutation, updates, native hooks, sensitive reserved namespaces, और high-risk approvals के लिए आवश्यक।
`operator.pairing`	Device और node pairing management, जिसमें pairing records या device tokens को list करना, approve करना, reject करना, remove करना, rotate करना, और revoke करना शामिल है।
`operator.approvals`	Exec और plugin approval APIs.
`operator.talk.secrets`	secrets सहित Talk configuration पढ़ना।

अज्ञात भविष्य के operator.* scopes के लिए exact match आवश्यक है, जब तक caller के पास operator.admin न हो।

Method scope केवल पहला gate है

हर Gateway RPC का एक least-privilege method scope होता है। वह method scope तय करता है कि request handler तक पहुंच सकती है या नहीं। कुछ handlers फिर approve या mutate की जा रही ठोस चीज़ के आधार पर अधिक कठोर approval-time checks लागू करते हैं।

उदाहरण:

device.pair.approve operator.pairing के साथ reachable है, लेकिन किसी operator device को approve करना केवल वही scopes mint या preserve कर सकता है जो caller के पास पहले से हैं।
node.pair.approve operator.pairing के साथ reachable है, फिर pending node command list से अतिरिक्त approval scopes derive करता है।
chat.send सामान्यतः write-scoped method है, लेकिन persistent /config set और /config unset के लिए command level पर operator.admin आवश्यक है।

यह lower-scope operators को सभी pairing approval को admin-only बनाए बिना low-risk pairing actions करने देता है।

Device pairing approvals

Device pairing records approved roles और scopes का durable source हैं। पहले से paired devices को चुपचाप व्यापक access नहीं मिलता: reconnects जो broader role या broader scopes मांगते हैं, एक नई pending upgrade request बनाते हैं।

Device request approve करते समय:

बिना operator role वाली request को operator token scope approval की आवश्यकता नहीं होती।
किसी non-operator device role, जैसे node, के लिए request को operator.admin चाहिए, भले ही device.pair.approve operator.pairing के साथ reachable हो।
operator.read, operator.write, operator.approvals, operator.pairing, या operator.talk.secrets के लिए request में caller के पास वे scopes, या operator.admin, होना आवश्यक है।
operator.admin के लिए request को operator.admin चाहिए।
बिना explicit scopes वाली repair request मौजूदा operator token scopes inherit कर सकती है। यदि वह मौजूदा token admin-scoped है, तो approval के लिए फिर भी operator.admin आवश्यक है।

Non-admin shared-secret और trusted-proxy sessions operator-device requests को केवल अपने घोषित operator scopes के भीतर approve कर सकते हैं। Non-operator roles approve करना admin-only है, भले ही वे sessions अन्यथा operator.pairing का उपयोग कर सकते हों।

Paired-device token sessions के लिए, management भी self-scoped है जब तक caller के पास operator.admin न हो: non-admin callers केवल अपनी pairing entries देखते हैं, केवल अपनी pending request approve या reject कर सकते हैं, और केवल अपनी device entry rotate, revoke, या remove कर सकते हैं।

Node pairing approvals

Legacy node.pair.* एक अलग Gateway-owned node pairing store का उपयोग करता है। WS nodes role: node के साथ device pairing का उपयोग करते हैं, लेकिन वही approval-level vocabulary लागू होती है।

node.pair.approve pending request command list का उपयोग करके अतिरिक्त required scopes derive करता है:

Commandless request: operator.pairing
Non-exec node commands: operator.pairing + operator.write
system.run, system.run.prepare, या system.which: operator.pairing + operator.admin

Node pairing identity और trust स्थापित करता है। यह node की अपनी system.run exec approval policy को replace नहीं करता।

Shared-secret auth

Shared gateway token/password auth को उस Gateway के लिए trusted operator access माना जाता है। OpenAI-compatible HTTP surfaces, /tools/invoke, और HTTP session history endpoints shared-secret bearer auth के लिए सामान्य full operator default scope set को restore करते हैं, भले ही caller narrower declared scopes भेजे।

Identity-bearing modes, जैसे trusted proxy auth या private-ingress none, फिर भी explicit declared scopes का सम्मान कर सकते हैं। वास्तविक trust boundary separation के लिए अलग Gateways का उपयोग करें।

Was this useful?