---
read_when:
    - اشکال‌زدایی خطاهای ناشی از نبود محدوده دسترسی اپراتور
    - بررسی تأییدیه‌های جفت‌سازی دستگاه یا Node
    - افزودن یا دسته‌بندی متدهای RPC در Gateway
summary: نقش‌ها و دامنه‌های عمل اپراتور و بررسی‌های زمان تأیید برای کلاینت‌های Gateway
title: دامنه‌های اپراتور
x-i18n:
    generated_at: "2026-07-16T16:56:02Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 5e74cdd87d21a9e0eafea6b7e4b18ab2e5b74e6c570603b1d4ad4dff83c65619
    source_path: gateway/operator-scopes.md
    workflow: 16
---

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

مرتبط: [امنیت](/fa/gateway/security)، [پروتکل Gateway](/fa/gateway/protocol)،
[جفت‌سازی Gateway](/fa/gateway/pairing)، [CLI دستگاه‌ها](/fa/cli/devices).

## نقش‌ها

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

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

متدهای RPC اپراتور به نقش `operator` نیاز دارند؛ متدهای مبدأگرفته از Node
به نقش `node` نیاز دارند.

## سطوح دامنه

| دامنه                   | معنا                                                                                                                                                       |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `operator.read`         | وضعیت فقط‌خواندنی، فهرست‌ها، کاتالوگ، گزارش‌ها، خواندن نشست‌ها و دیگر فراخوانی‌های بدون تغییر.                                                                          |
| `operator.write`        | اقدامات تغییردهندهٔ اپراتور: ارسال پیام، فراخوانی ابزارها، به‌روزرسانی تنظیمات گفت‌وگو/صدا و رلهٔ فرمان Node. همچنین الزامات `operator.read` را برآورده می‌کند.                |
| `operator.admin`        | دسترسی مدیریتی. الزامات همهٔ دامنه‌های `operator.*` را برآورده می‌کند. برای تغییر پیکربندی، به‌روزرسانی‌ها، هوک‌های بومی، فضای نام‌های رزروشده و تأییدهای پرخطر لازم است. |
| `operator.pairing`      | مدیریت جفت‌سازی دستگاه و Node: فهرست‌کردن، تأیید، رد، حذف، چرخش و لغو.                                                                            |
| `operator.approvals`    | APIهای تأیید اجرای فرمان و Plugin.                                                                                                                                |
| `operator.talk.secrets` | خواندن پیکربندی گفت‌وگو با احتساب اطلاعات محرمانه.                                                                                                             |

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

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

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

- `device.pair.approve` با `operator.pairing` قابل دسترسی است، اما تأیید یک
  دستگاه اپراتور فقط می‌تواند دامنه‌هایی را صادر یا حفظ کند که فراخواننده از قبل دارد.
- `node.pair.approve` با `operator.pairing` قابل دسترسی است و سپس دامنه‌های
  تأیید اضافی را از فهرست فرمان‌های اعلام‌شدهٔ Node در انتظار استخراج می‌کند.
- `chat.send` متدی با دامنهٔ نوشتن است، اما فرمان‌های چت
  `/config set` و `/config unset` علاوه بر آن به `operator.admin`
  نیاز دارند، فارغ از دامنهٔ ارسال چت فراخواننده.

این کار به اپراتورهای دارای دامنهٔ محدودتر اجازه می‌دهد اقدامات جفت‌سازی کم‌خطر را انجام دهند،
بدون اینکه همهٔ تأییدهای جفت‌سازی فقط به مدیر محدود شوند.

## تأییدهای جفت‌سازی دستگاه

رکوردهای جفت‌سازی دستگاه منبع پایدار نقش‌ها و دامنه‌های تأییدشده هستند.
دستگاهی که از قبل جفت شده است، بی‌سروصدا دسترسی گسترده‌تری دریافت نمی‌کند: اتصال مجددی
که نقش یا دامنه‌های گسترده‌تری درخواست کند، یک درخواست ارتقای جدید در انتظار ایجاد می‌کند.

هنگام تأیید درخواست دستگاه:

- درخواستی که نقش اپراتور ندارد، به تأیید دامنهٔ اپراتور نیاز ندارد.
- درخواست نقش دستگاهی غیر از اپراتور (برای مثال `node`) به
  `operator.admin` نیاز دارد، هرچند خود `device.pair.approve` فقط به
  `operator.pairing` نیاز دارد.
- درخواست `operator.read`، `operator.write`، `operator.approvals`،
  `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](/fa/gateway/pairing) را ببینید.

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

| فرمان‌های اعلام‌شده                                                                                                    | دامنه‌های موردنیاز                       |
| -------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| هیچ‌کدام                                                                                                                 | `operator.pairing`                    |
| فرمان‌های معمولی Node                                                                                               | `operator.pairing` + `operator.write` |
| `system.run`، `system.run.prepare`، `system.which`، `browser.proxy`، `fs.listDir` یا `system.execApprovals.get/set` | `operator.pairing` + `operator.admin` |

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

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

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

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

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