دامنه‌های اپراتور

دامنه‌های عملگر تعیین می‌کنند که یک کلاینت Gateway پس از احراز هویت چه کارهایی می‌تواند انجام دهد. آن‌ها یک سازوکار حفاظتی صفحهٔ کنترل درون یک دامنهٔ عملگر مورداعتماد Gateway هستند، نه جداسازی چندمستاجری در برابر عوامل متخاصم. برای جداسازی قوی میان افراد، تیم‌ها یا دستگاه‌ها، Gatewayهای جداگانه‌ای را تحت کاربران یا میزبان‌های جداگانهٔ سیستم‌عامل اجرا کنید.

مرتبط: امنیت، پروتکل Gateway، جفت‌سازی Gateway، CLI دستگاه‌ها.

نقش‌ها

هر کلاینت WebSocket مربوط به Gateway با یک نقش متصل می‌شود:

• operator: کلاینت‌های صفحهٔ کنترل مانند CLI، رابط کاربری کنترل، خودکارسازی و فرایندهای کمکی مورداعتماد.
• node: میزبان‌های قابلیت (macOS، iOS، Android، بدون رابط کاربری) که فرمان‌ها را از طریق node.invoke ارائه می‌کنند.

متدهای RPC عملگر به نقش operator نیاز دارند؛ متدهایی که از Node منشأ می‌گیرند به نقش node نیاز دارند.

سطوح دامنه

دامنه‌های ناشناختهٔ آیندهٔ operator.* به تطبیق دقیق نیاز دارند، مگر اینکه فراخواننده از قبل operator.admin را داشته باشد.

دامنهٔ متد فقط نخستین دروازه است

هر RPC مربوط به Gateway یک دامنهٔ متد با حداقل سطح دسترسی دارد که تعیین می‌کند آیا درخواست به کنترل‌کنندهٔ آن می‌رسد یا نه. متدهای آگاه از پارامتر، این دامنه را پیش از ارسال استخراج می‌کنند تا خطاهای مجوزدهی یک پاسخ ساخت‌یافتهٔ معیار داشته باشند:

• 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.* از یک مخزن جفت‌سازی Node جداگانه و متعلق به Gateway استفاده می‌کنند. Nodeهای WS به‌جای آن از جفت‌سازی دستگاه (role: node) استفاده می‌کنند، اما همان واژگان تأیید اعمال می‌شود. برای چگونگی ارتباط این دو مخزن، جفت‌سازی Gateway را ببینید.

node.pair.approve دامنه‌های الزامی اضافی را از فهرست فرمان‌های درخواست در انتظار استخراج می‌کند:

تأیید اعلامیهٔ یک Node، فرمان‌هایی را که دروازهٔ جداگانهٔ فهرست مجاز زمان اجرا دارند فعال نمی‌کند. برای مثال، تأیید Nodeای که computer.act را اعلام می‌کند به جفت‌سازی به‌علاوهٔ دامنهٔ نوشتن نیاز دارد، اما فقط آن سطح را ثبت می‌کند. یک مدیر یا مالک همچنان باید computer.act را فعال کند. تا زمانی که فعال باقی می‌ماند، فراخوانی آن از طریق node.invoke به دامنهٔ نوشتن نیاز دارد، اما برای هر اقدام به دامنهٔ مدیریتی نیاز ندارد.

جفت‌سازی Node هویت و اعتماد را برقرار می‌کند؛ جایگزین سیاست تأیید اجرای system.run خود Node نمی‌شود.

احراز هویت با راز مشترک

احراز هویت با توکن/گذرواژهٔ مشترک Gateway برای آن Gateway به‌عنوان دسترسی عملگر مورداعتماد در نظر گرفته می‌شود. سطوح HTTP سازگار با OpenAI، /tools/invoke و نقاط پایانی HTTP تاریخچهٔ نشست، مجموعهٔ کامل دامنه‌های پیش‌فرض عملگر را برای احراز هویت حامل با راز مشترک بازیابی می‌کنند، حتی اگر فراخواننده دامنه‌های اعلام‌شدهٔ محدودتری ارسال کند.

حالت‌های دارای هویت، مانند احراز هویت پروکسی مورداعتماد یا none ورودی خصوصی، همچنان می‌توانند دامنه‌های صریح اعلام‌شده را رعایت کنند. برای جداسازی واقعی مرز اعتماد از Gatewayهای جداگانه استفاده کنید.