---
read_when:
    - اشکال‌زدایی خطاهای نبود محدودهٔ عملگر
    - بررسی تأییدهای جفت‌سازی دستگاه یا Node
    - افزودن یا طبقه‌بندی متدهای RPC Gateway
summary: نقش‌های اپراتور، محدوده‌ها، و بررسی‌های هنگام تأیید برای کلاینت‌های Gateway
title: دامنه‌های اپراتور
x-i18n:
    generated_at: "2026-05-04T02:26:05Z"
    model: gpt-5.5
    provider: openai
    source_hash: f05d6bdbf9bdad2aef1c9664bb7ebb4b6241334b8aefac7993104e9977e40450
    source_path: gateway/operator-scopes.md
    workflow: 16
---

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

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

## نقش‌ها

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

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

روش‌های RPC عملگر به نقش `operator` نیاز دارند. روش‌هایی که از Node آغاز می‌شوند
به نقش `node` نیاز دارند.

## سطوح دامنه

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

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

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

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

نمونه‌ها:

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

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

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

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

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

- درخواستی که نقش عملگر ندارد به تأیید دامنه توکن عملگر نیاز ندارد.
- درخواست برای `operator.read`، `operator.write`، `operator.approvals`،
  `operator.pairing`، یا `operator.talk.secrets` نیاز دارد که فراخواننده
  همان دامنه‌ها، یا `operator.admin`، را داشته باشد.
- درخواست برای `operator.admin` به `operator.admin` نیاز دارد.
- درخواست تعمیر بدون دامنه‌های صریح می‌تواند دامنه‌های توکن عملگر موجود را
  به ارث ببرد. اگر آن توکن موجود دامنه admin داشته باشد، تأیید همچنان به
  `operator.admin` نیاز دارد.

برای نشست‌های توکن دستگاه جفت‌شده، مدیریت خوددامنه است مگر اینکه فراخواننده
`operator.admin` نیز داشته باشد: فراخوانندگان غیرمدیر فقط ورودی‌های جفت‌سازی
خودشان را می‌بینند، فقط می‌توانند درخواست در انتظار خودشان را تأیید یا رد کنند،
و فقط می‌توانند ورودی دستگاه خودشان را بچرخانند، لغو کنند، یا حذف کنند.

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

`node.pair.*` قدیمی از یک مخزن جفت‌سازی Node جداگانه که متعلق به Gateway است استفاده می‌کند. Nodeهای WS
از جفت‌سازی دستگاه با `role: node` استفاده می‌کنند، اما همان واژگان سطح تأیید
اعمال می‌شود.

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

- درخواست بدون فرمان: `operator.pairing`
- فرمان‌های Node غیر exec: `operator.pairing` + `operator.write`
- `system.run`، `system.run.prepare`، یا `system.which`:
  `operator.pairing` + `operator.admin`

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

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

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

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