موافقات التنفيذ — متقدم

موضوعات متقدمة لموافقات التنفيذ: المسار السريع safeBins، وربط المفسّر/بيئة التشغيل، وإعادة توجيه الموافقات إلى قنوات الدردشة (بما في ذلك التسليم الأصلي). للاطلاع على السياسة الأساسية وتدفق الموافقات، راجع موافقات التنفيذ.

الأدوات الآمنة (الإدخال القياسي فقط)

يسمّي tools.exec.safeBins البرامج الثنائية التي تعمل بالإدخال القياسي فقط (مثل cut) والتي تعمل في وضع قائمة السماح من دون إدخالات صريحة في قائمة السماح. ترفض الأدوات الآمنة وسائط الملفات الموضعية والرموز الشبيهة بالمسارات، لذا لا يمكنها العمل إلا على التدفق الوارد. تعامل مع هذا بوصفه مسارًا سريعًا محدودًا لمرشحات التدفق، وليس قائمة ثقة عامة.

الأدوات الآمنة الافتراضية:

cut، uniq، head، tail، tr، wc

لا يندرج grep وsort ضمن القائمة الافتراضية. إذا فعّلتهما، فأبقِ إدخالات صريحة في قائمة السماح لمسارات عملهما التي لا تعتمد على الإدخال القياسي. بالنسبة إلى grep في وضع الأداة الآمنة، قدّم النمط باستخدام -e/--regexp؛ إذ يُرفض شكل النمط الموضعي حتى لا يمكن تمرير معاملات الملفات خلسةً كوسائط موضعية ملتبسة.

التحقق من argv والعلامات المرفوضة

يكون التحقق حتميًا اعتمادًا على بنية argv فقط (من دون فحوصات لوجود الملفات في نظام ملفات المضيف)، مما يمنع سلوك استقراء وجود الملفات من اختلافات السماح/الرفض. تُرفض الخيارات الموجهة للملفات في الأدوات الآمنة الافتراضية؛ وتُتحقق الخيارات الطويلة وفق مبدأ الرفض عند الإخفاق (تُرفض العلامات المجهولة والاختصارات الملتبسة). تُقبل العلامات المنطقية المعروفة والمخصصة للقراءة فقط في الأدوات الافتراضية (مثل wc -l، وtr -d، وuniq -c)، بينما تبقى العلامات القصيرة غير المعروفة مرفوضة عند الإخفاق وتنتقل إلى الموافقة اليدوية.

العلامات المرفوضة حسب ملف الأداة الآمنة:

• grep: --dereference-recursive، --directories، --exclude-from، --file، --recursive، -R، -d، -f، -r
• jq: --argfile، --from-file، --library-path، --rawfile، --slurpfile، -L، -f
• sort: --compress-program، --files0-from، --output، --random-source، --temporary-directory، -T، -o
• tail: --follow، --retry، -F، -f
• wc: --files0-from

تفرض الأدوات الآمنة أيضًا معاملة رموز argv بوصفها نصًا حرفيًا وقت التنفيذ (من دون توسيع أحرف البدل ولا توسيع $VARS) للمقاطع المعتمدة على الإدخال القياسي فقط، لذا لا يمكن استخدام أنماط مثل * أو $HOME/... لتمرير عمليات قراءة الملفات خلسةً. تُرفض awk، وsed، وjq دائمًا كأدوات آمنة لأنه لا يمكن التحقق من اقتصار دلالاتها على الإدخال القياسي: يمكن لـ jq قراءة بيانات البيئة وتحميل شيفرة jq من الوحدات أو ملفات بدء التشغيل. استخدم إدخالًا صريحًا في قائمة السماح أو مطالبة موافقة لهذه الأدوات بدلًا من safeBins.

أدلة البرامج الثنائية الموثوقة

يجب أن تُحلّ الأدوات الآمنة من أدلة البرامج الثنائية الموثوقة (الإعدادات الافتراضية للنظام إضافةً إلى tools.exec.safeBinTrustedDirs الاختياري). لا تُوثق إدخالات PATH تلقائيًا أبدًا. الأدلة الافتراضية الموثوقة محدودة عمدًا: /bin، و/usr/bin. إذا كان ملف الأداة الآمنة القابل للتنفيذ موجودًا في مسارات مدير الحزم/المستخدم (مثل /opt/homebrew/bin، و/usr/local/bin، و/opt/local/bin، و/snap/bin)، فأضفها صراحةً إلى tools.exec.safeBinTrustedDirs.

تسلسل الصدفة، والمغلّفات، والمضاعِفات

يُسمح بتسلسل الصدفة (&&، و||، و;) عندما يستوفي كل مقطع من المستوى الأعلى قائمة السماح (بما في ذلك الأدوات الآمنة أو السماح التلقائي لـ Skills). تظل عمليات إعادة التوجيه غير مدعومة في وضع قائمة السماح. يُرفض استبدال الأوامر ($() / علامات الاقتباس الخلفية) أثناء تحليل قائمة السماح، بما في ذلك داخل علامات الاقتباس المزدوجة؛ استخدم علامات الاقتباس المفردة إذا احتجت إلى نص $() حرفي.

في موافقات التطبيق المرافق على macOS، يُعامل نص الصدفة الخام الذي يحتوي على بناء تحكم أو توسيع للصدفة (&&، و||، و;، و|، و`، و$، و<، و>، و(، و)) بوصفه غير مطابق لقائمة السماح ما لم يكن برنامج الصدفة الثنائي نفسه مدرجًا في قائمة السماح.

بالنسبة إلى مغلّفات الصدفة (bash|sh|zsh ... -c/-lc)، تُختزل تجاوزات البيئة ذات نطاق الطلب إلى قائمة سماح صريحة صغيرة (TERM، وLANG، وLC_*، وCOLORTERM، وNO_COLOR، وFORCE_COLOR).

بالنسبة إلى قرارات allow-always في وضع قائمة السماح، تحفظ مغلّفات الإرسال الشفافة (مثل env، وflock، وnice، وnohup، وstdbuf، وtimeout) مسار الملف القابل للتنفيذ الداخلي بدلًا من مسار المغلّف. تُفك مضاعِفات الصدفة (busybox، وtoybox) لتطبيقات الصدفة المصغرة (sh، وash، إلخ) بالطريقة نفسها. إذا تعذّر فك مغلّف أو مضاعِف بأمان، فلا يُحفظ أي إدخال في قائمة السماح تلقائيًا.

إذا أضفت مفسّرات مثل python3 أو node إلى قائمة السماح، ففضّل tools.exec.strictInlineEval=true حتى يظل التقييم المضمّن متطلبًا لموافقة صريحة. في الوضع الصارم، لا يزال بإمكان allow-always حفظ استدعاءات المفسّر/البرنامج النصي السليمة، لكن لا تُحفظ حوامل التقييم المضمّن تلقائيًا.

الأدوات الآمنة مقابل قائمة السماح

موقع الإعداد:

• يأتي safeBins من الإعداد (tools.exec.safeBins أو agents.list[].tools.exec.safeBins الخاص بكل وكيل).
• يأتي safeBinTrustedDirs من الإعداد (tools.exec.safeBinTrustedDirs أو agents.list[].tools.exec.safeBinTrustedDirs الخاص بكل وكيل).
• يأتي safeBinProfiles من الإعداد (tools.exec.safeBinProfiles أو agents.list[].tools.exec.safeBinProfiles الخاص بكل وكيل). تتجاوز مفاتيح الملف الشخصي الخاصة بكل وكيل المفاتيح العامة.
• توجد إدخالات قائمة السماح في ملف الموافقات المحلي للمضيف ضمن agents.<id>.allowlist (أو عبر واجهة التحكم / openclaw approvals allowlist ...).
• يحذّر openclaw security audit باستخدام tools.exec.safe_bins_interpreter_unprofiled عندما تظهر أدوات المفسّر/بيئة التشغيل الثنائية في safeBins من دون ملفات شخصية صريحة.
• يمكن لـ openclaw doctor --fix إنشاء هيكل أولي لإدخالات safeBinProfiles.<bin> المخصصة المفقودة بوصفها {} (راجعها وضيّق نطاقها بعد ذلك). لا تُنشأ هياكل أدوات المفسّر/بيئة التشغيل الثنائية تلقائيًا.

مثال على ملف شخصي مخصص:

{  tools: {    exec: {      safeBins: ["myfilter"],      safeBinProfiles: {        myfilter: {          minPositional: 0,          maxPositional: 0,          allowedValueFlags: ["-n", "--limit"],          deniedFlags: ["-f", "--file", "-c", "--command"],        },      },    },  },}

أوامر المفسّر/بيئة التشغيل

تكون عمليات تشغيل المفسّر/بيئة التشغيل المدعومة بالموافقة متحفظة عمدًا:

• يُربط دائمًا سياق argv/cwd/env الدقيق.
• تُربط أشكال برامج الصدفة النصية المباشرة وملفات بيئة التشغيل المباشرة، بأفضل جهد، بلقطة واحدة محددة لملف محلي.
• تُفك أشكال مغلّفات مديري الحزم الشائعة التي تظل تُحلّ إلى ملف محلي مباشر واحد (مثل pnpm exec، وpnpm node، وnpm exec، وnpx) قبل الربط.
• إذا تعذّر على OpenClaw تحديد ملف محلي واحد محدد بالضبط لأمر مفسّر/بيئة تشغيل (مثل برامج الحزم النصية، أو أشكال التقييم، أو سلاسل المحمّلات الخاصة ببيئة التشغيل، أو الأشكال متعددة الملفات الملتبسة)، يُرفض التنفيذ المدعوم بالموافقة بدلًا من ادعاء تغطية دلالية لا يملكها.
• بالنسبة إلى مسارات العمل هذه، فضّل العزل، أو حدًا منفصلًا للمضيف، أو مسار عمل كاملًا/قائمة سماح موثوقة وصريحة يقبل فيه المشغّل دلالات بيئة التشغيل الأوسع.

عندما تكون الموافقات مطلوبة، تعيد أداة التنفيذ فورًا معرّف موافقة. استخدم ذلك المعرّف لربط أحداث نظام التشغيل المعتمد اللاحقة (Exec finished، وكذلك Exec running عند إعداده). إذا لم يصل أي قرار قبل انتهاء المهلة، يُعامل الطلب بوصفه انتهاء مهلة للموافقة ويظهر كرفض نهائي لأمر المضيف. بالنسبة إلى الموافقات غير المتزامنة للوكيل الرئيسي ذات الجلسة المنشئة، يستأنف OpenClaw أيضًا تلك الجلسة بمتابعة داخلية كي يلاحظ الوكيل أن الأمر لم يُشغّل بدلًا من إصلاح نتيجة مفقودة لاحقًا. تنتهي صلاحية موافقات التنفيذ المعلّقة بعد 30 دقيقة افتراضيًا.

سلوك تسليم المتابعة

بعد اكتمال تنفيذ غير متزامن معتمد، يرسل OpenClaw دور متابعة agent إلى الجلسة نفسها. تستخدم الموافقات غير المتزامنة المرفوضة مسار متابعة الجلسة الرئيسية نفسه لحالة الرفض، لكنها لا تسجّل عمليات تسليم مرتفعة الصلاحيات لبيئة التشغيل ولا تشغّل الأمر. أما حالات الرفض التي لا تتضمن جلسة رئيسية قابلة للاستئناف فتُحجب أو يُبلّغ عنها عبر مسار مباشر آمن عند توفره.

• إذا وُجد هدف تسليم خارجي صالح (قناة قابلة للتسليم مع هدف to)، يستخدم تسليم المتابعة تلك القناة.
• في تدفقات دردشة الويب فقط أو الجلسات الداخلية التي لا تتضمن هدفًا خارجيًا، يظل تسليم المتابعة مقتصرًا على الجلسة (deliver: false).
• إذا طلب المستدعي صراحةً تسليمًا خارجيًا صارمًا من دون قناة خارجية قابلة للحل، يفشل الطلب باستخدام INVALID_REQUEST.
• إذا كان bestEffortDeliver مفعّلًا وتعذّر حل أي قناة خارجية، يُخفّض التسليم إلى الجلسة فقط بدلًا من الفشل.

إعادة توجيه الموافقات إلى قنوات الدردشة

يمكن إعادة توجيه مطالبات موافقة التنفيذ إلى أي قناة دردشة (بما في ذلك قنوات Plugin) واعتمادها باستخدام /approve. يستخدم هذا خط أنابيب التسليم الصادر المعتاد.

الإعداد:

{  approvals: {    exec: {      enabled: true,      mode: "session", // "session" | "targets" | "both"      agentFilter: ["main"],      sessionFilter: ["discord"], // substring or regex      targets: [        { channel: "slack", to: "U12345678" },        { channel: "telegram", to: "123456789" },      ],    },  },}

الرد في الدردشة:

/approve <id> allow-once/approve <id> allow-always/approve <id> deny

يتعامل الأمر /approve مع كلٍ من موافقات التنفيذ وموافقات الـ Plugin. إذا لم يطابق المعرّف موافقة تنفيذ معلّقة، فإنه يتحقق تلقائيًا من موافقات الـ Plugin بدلًا من ذلك. يقتصر هذا الرجوع الاحتياطي على حالات فشل «الموافقة غير موجودة»؛ أما الرفض أو الخطأ الفعلي في موافقة التنفيذ فلا يؤدي إلى إعادة المحاولة بصمت باعتبارها موافقة Plugin.

إعادة توجيه موافقات الـ Plugin

تستخدم إعادة توجيه موافقات الـ Plugin مسار التسليم نفسه المستخدم لموافقات التنفيذ، لكنها تملك إعدادًا مستقلًا خاصًا بها ضمن approvals.plugin. لا يؤثر تمكين أحدهما أو تعطيله في الآخر. للاطلاع على سلوك تأليف الـ Plugin وحقول الطلب ودلالات القرار، راجع طلبات أذونات الـ Plugin.

{  approvals: {    plugin: {      enabled: true,      mode: "targets",      agentFilter: ["main"],      targets: [        { channel: "slack", to: "U12345678" },        { channel: "telegram", to: "123456789" },      ],    },  },}

بنية الإعداد مطابقة لـ approvals.exec: تعمل enabled وmode وagentFilter وsessionFilter وtargets بالطريقة نفسها.

تعرض القنوات التي تدعم الردود التفاعلية المشتركة أزرار الموافقة نفسها لكلٍ من موافقات التنفيذ وموافقات الـ Plugin. أما القنوات التي لا تملك واجهة مستخدم تفاعلية مشتركة، فتعود إلى نص عادي يتضمن تعليمات /approve. قد تقيّد طلبات موافقة الـ Plugin القرارات المتاحة: تستخدم واجهات الموافقة مجموعة القرارات المعلنة في الطلب، ويرفض Gateway محاولات إرسال قرار لم يكن معروضًا.

الموافقات داخل المحادثة نفسها على أي قناة

عندما ينشأ طلب موافقة تنفيذ أو Plugin من واجهة محادثة قابلة للتسليم، يمكن للمحادثة نفسها الموافقة عليه باستخدام /approve افتراضيًا. ينطبق ذلك على Slack وMatrix وMicrosoft Teams والمحادثات المماثلة القابلة للتسليم، بالإضافة إلى مسارات واجهة الويب وواجهة الطرفية الحالية، باستخدام نموذج مصادقة القناة المعتاد لتلك المحادثة. إذا كانت المحادثة الأصلية تستطيع بالفعل إرسال الأوامر وتلقي الردود، فلن تحتاج طلبات الموافقة بعد الآن إلى محوّل تسليم أصلي منفصل لمجرد بقائها معلّقة.

يدعم Discord وTelegram وبوت QQ أيضًا /approve داخل المحادثة نفسها، لكن هذه القنوات تظل تستخدم قائمة الموافقين المحسومة لديها للتفويض حتى عند تعطيل تسليم الموافقات الأصلي.

تسليم الموافقات الأصلي

يمكن لبعض القنوات أيضًا العمل كعملاء أصليين للموافقة: Discord وSlack وTelegram وMatrix وبوت QQ. يضيف العملاء الأصليون رسائل خاصة للموافقين، وتوزيعًا إلى المحادثة الأصلية، وتجربة مستخدم تفاعلية للموافقة خاصة بالقناة فوق مسار /approve المشترك داخل المحادثة نفسها.

عندما تتوفر بطاقات أو أزرار موافقة أصلية، تكون واجهة المستخدم الأصلية تلك هي المسار الأساسي الموجّه إلى الوكيل. ينبغي ألا يكرر الوكيل أيضًا أمر /approve نصيًا داخل المحادثة، ما لم تُفد نتيجة الأداة بأن موافقات المحادثة غير متاحة أو أن الموافقة اليدوية هي المسار الوحيد المتبقي.

إذا كان عميل موافقة أصلي مهيّأ، لكن لا يوجد وقت تشغيل أصلي نشط للقناة الأصلية، يُبقي OpenClaw مطالبة /approve المحلية والحتمية ظاهرة. وإذا كان وقت التشغيل الأصلي نشطًا وحاول التسليم، لكن لم يتلقَّ أي هدف البطاقة، يرسل OpenClaw إشعار رجوع احتياطي داخل المحادثة نفسها يتضمن أمر /approve <id> <decision> الدقيق، بحيث يظل من الممكن حسم الطلب.

النموذج العام:

• تظل سياسة تنفيذ المضيف هي التي تقرر ما إذا كانت موافقة التنفيذ مطلوبة
• يتحكم approvals.exec في إعادة توجيه مطالبات الموافقة إلى وجهات محادثة أخرى
• يتحكم channels.<channel>.execApprovals في تمكين العملاء الأصليين الخاصين بقنوات Discord وSlack وTelegram وبوت QQ والقنوات المماثلة
• يمكن لموافقات Plugin في Slack استخدام عميل الموافقة الأصلي في Slack عندما يأتي الطلب من Slack ويُحسم الموافقون على Plugin في Slack؛ كما يمكن لـ approvals.plugin توجيه موافقات الـ Plugin إلى جلسات أو أهداف Slack حتى عندما تكون موافقات التنفيذ في Slack معطلة
• تتعامل بطاقات الموافقة الأصلية في Google Chat مع موافقات التنفيذ والـ Plugin الناشئة من مساحات أو سلاسل Google Chat عندما يُحسم الموافقون المستقرون في users/<id> من dm.allowFrom أو defaultTo؛ وهي لا تستخدم أحداث التفاعل لاتخاذ القرارات
• يخضع تسليم الموافقات عبر التفاعلات في WhatsApp وSignal لـ approvals.exec و approvals.plugin؛ ولا توجد لديهما كتل channels.<channel>.execApprovals

يُمكّن العملاء الأصليون تلقائيًا التسليم إلى الرسائل الخاصة أولًا عندما تتحقق جميع الشروط التالية:

• تدعم القناة تسليم الموافقات الأصلي
• يمكن حسم الموافقين من execApprovals.approvers الصريح أو من هوية المالك مثل commands.ownerAllowFrom
• تكون channels.<channel>.execApprovals.enabled غير مضبوطة أو تساوي "auto"

اضبط enabled: false لتعطيل عميل موافقة أصلي صراحةً. واضبط enabled: true لفرض تمكينه عند حسم الموافقين. يظل التسليم العام إلى المحادثة الأصلية صريحًا من خلال channels.<channel>.execApprovals.target. عندما تُمكّن target الأصلية التسليم إلى المحادثة الأصلية، تتضمن مطالبات الموافقة نص الأمر.

الأسئلة الشائعة: لماذا يوجد إعدادان لموافقات التنفيذ الخاصة بموافقات المحادثة؟

• Discord: ‏channels.discord.execApprovals.*
• Slack: ‏channels.slack.execApprovals.*
• Telegram: ‏channels.telegram.execApprovals.*
• بوت QQ: ‏channels.qqbot.execApprovals.*
• Google Chat: هيّئ الموافقين المستقرين باستخدام channels.googlechat.dm.allowFrom أو channels.googlechat.defaultTo؛ لا يلزم وجود كتلة execApprovals
• WhatsApp: استخدم approvals.exec وapprovals.plugin لتوجيه مطالبات الموافقة إلى WhatsApp
• Signal: استخدم approvals.exec وapprovals.plugin لتوجيه مطالبات الموافقة إلى Signal

التوجيه الخاص بالعملاء الأصليين:

• يستخدم Telegram افتراضيًا الرسائل الخاصة للموافقين (target: "dm"). انتقل إلى channel أو both لعرض مطالبات الموافقة أيضًا في محادثة أو موضوع Telegram الأصلي. بالنسبة إلى موضوعات منتديات Telegram، يحافظ OpenClaw على الموضوع في مطالبة الموافقة والمتابعة اللاحقة للموافقة.
• يمكن أن يكون الموافقون في Discord وTelegram صريحين (execApprovals.approvers) أو مستنتجين من commands.ownerAllowFrom؛ ولا يمكن الموافقة أو الرفض إلا للموافقين الذين تم حسمهم.
• يمكن أن يكون الموافقون في Slack صريحين (execApprovals.approvers) أو مستنتجين من commands.ownerAllowFrom. تستخدم رسائل موافقات Plugin الخاصة في Slack موافقي Plugin في Slack من allowFrom والتوجيه الافتراضي للحساب، لا موافقي تنفيذ Slack. تحافظ أزرار Slack الأصلية على نوع معرّف الموافقة، لذا يمكن لمعرّفات plugin: حسم موافقات الـ Plugin من دون طبقة رجوع احتياطي محلية ثانية خاصة بـ Slack.
• تحافظ بطاقات Google Chat الأصلية على رجوع /approve اليدوي في نص الرسالة، لكن استدعاءات أزرار البطاقة لا تحمل سوى رموز إجراءات مبهمة؛ ويُستعاد معرّف الموافقة والقرار من الحالة المعلّقة على جانب الخادم.
• تتعامل موافقات الرموز التعبيرية في WhatsApp مع كلٍ من مطالبات التنفيذ والـ Plugin عندما توجّه عائلة إعادة التوجيه المطابقة على المستوى الأعلى إلى WhatsApp. ترتبط المطالبات الأصلية مباشرةً؛ ويربط التسليم المشترك في وضع الأهداف بيانات الموافقة الوصفية ذات النوع نفسها بإيصال رسالة WhatsApp المقبول.
• تتعامل موافقات التفاعل في Signal مع كلٍ من مطالبات التنفيذ والـ Plugin فقط عندما تكون عائلة إعادة التوجيه المطابقة على المستوى الأعلى مُمكّنة وتوجّه إلى Signal. يمكن لموافقات تنفيذ Signal المباشرة داخل المحادثة نفسها منع رجوع /approve المحلي دون موافقين صريحين؛ لكن حسم تفاعلات Signal لا يزال يتطلب موافقين صريحين في Signal من channels.signal.allowFrom أو defaultTo.
• يتعامل توجيه الرسائل الخاصة والقنوات الأصلي في Matrix واختصارات التفاعل مع كلٍ من موافقات التنفيذ والـ Plugin؛ ويظل تفويض الـ Plugin صادرًا من channels.matrix.dm.allowFrom. تتضمن مطالبات Matrix الأصلية محتوى حدث مخصصًا في com.openclaw.approval ضمن حدث المطالبة الأول، بحيث يمكن لعملاء Matrix المدركين لـ OpenClaw قراءة حالة الموافقة المنظّمة، بينما يحتفظ العملاء القياسيون برجوع /approve النصي العادي.
• تحمل أزرار الموافقة الأصلية في Discord وTelegram نوع مالك صريحًا، سواء للتنفيذ أو للـ Plugin، ضمن بيانات استدعاء خاصة بالنقل، ولا تحسم إلا ذلك المالك. تظل عناصر تحكم /approve الأقدم التي تفتقر إلى نوع مسار توافق محدودًا: فهي لا تجرب إلا أنواع المالك التي يجوز للجهة الفاعلة الموافقة عليها، ولا تتابع إلا بعد نتيجة تفيد بأن الموافقة غير موجودة، ولا تستنتج الملكية أبدًا من معرّف الموافقة.
• لا يلزم أن يكون مقدم الطلب من الموافقين.
• إذا لم تتمكن أي واجهة مشغّل أو عميل موافقة مهيّأ من قبول الطلب، تعود المطالبة إلى askFallback.

تستخدم أوامر المجموعات الحساسة والمقصورة على المالك، مثل /diagnostics و/export-trajectory، توجيهًا خاصًا للمالك لمطالبات الموافقة والنتائج النهائية. يحاول OpenClaw أولًا استخدام مسار خاص على الواجهة نفسها التي شغّل المالك الأمر منها. إذا لم يكن لتلك الواجهة مسار خاص للمالك، فإنه يعود إلى أول مسار متاح للمالك من commands.ownerAllowFrom، بحيث يظل بإمكان أمر مجموعة Discord إرسال الموافقة والنتيجة إلى رسالة Telegram الخاصة بالمالك عندما يكون Telegram هو الواجهة الخاصة الأساسية المهيّأة. ولا تتلقى محادثة المجموعة سوى إقرار قصير.

راجع:

• Discord
• Telegram
• بوت QQ

تطبيقات المشغّل الرسمية للأجهزة المحمولة

يمكن لتطبيقي iOS وAndroid الرسميين أيضًا مراجعة موافقات التنفيذ المعلّقة والتي يملكها Gateway عند استخدام اتصال operator.admin، أو عندما يكون جهاز operator.approvals المقترن بهما مستهدفًا صراحةً في الطلب. يقرآن السجل الدائم والمنقّح نفسه الذي تستخدمه واجهة التحكم، ويرسلان قرارًا مدركًا للنوع، ويعرضان نتيجة الإجابة الأولى القياسية من Gateway. تعكس Apple Watch مطالبات الموافقة هذه عبر جهاز iPhone المقترن، مع إجرائي السماح لمرة واحدة والرفض. لا يراجع وضع Gateway المباشر في الساعة الموافقات.

لا يجعل فقدان إقرار الحسم الخيار المرسل موثوقًا ونهائيًا: يعطّل التطبيق عناصر التحكم ويقرأ السجل مجددًا. إذا سبقت واجهة أخرى، يعرض التطبيق ذلك القرار المسجّل. تظل المطالبات المعلّقة مرتبطة بـ Gateway الذي أصدرها، لذا لا يمكن لتبديل Gateway النشط إعادة توجيه معرّف موافقة قديم.

مسار IPC في macOS

Gateway -> خدمة Node ‏(WS)                 |  IPC ‏(UDS + رمز + HMAC + TTL)                 v             تطبيق Mac ‏(واجهة المستخدم + الموافقات + system.run)

ملاحظات أمنية:

• وضع مقبس Unix هو 0600، ويُخزّن الرمز في exec-approvals.json.
• فحص النظير ذي UID نفسه.
• تحدٍ/استجابة (قيمة nonce + رمز HMAC + تجزئة الطلب) + مدة TTL قصيرة.

الأسئلة الشائعة

متى يُستخدم accountId وthreadId على هدف موافقة؟

استخدم accountId عندما تحتوي القناة على هويات مهيّأة متعددة ويجب أن تخرج مطالبة الموافقة عبر حساب محدد. استخدم threadId عندما تدعم الوجهة الموضوعات أو السلاسل، وينبغي أن تظل المطالبة داخل تلك السلسلة بدلًا من المحادثة ذات المستوى الأعلى.

من الأمثلة الملموسة في Telegram مجموعة عمليات فائقة تحتوي على موضوعات منتدى وحسابين لبوت Telegram. تسمّي قيمة to المجموعة الفائقة، ويحدد accountId حساب البوت، ويحدد threadId موضوع المنتدى:

{  approvals: {    exec: {      enabled: true,      mode: "targets",      targets: [        {          channel: "telegram",          to: "-1001234567890",          accountId: "ops-bot",          threadId: "77",        },      ],    },  },  channels: {    telegram: {      accounts: {        default: {          name: "البوت الأساسي",          botToken: "env:TELEGRAM_PRIMARY_BOT_TOKEN",        },        "ops-bot": {          name: "بوت العمليات",          botToken: "env:TELEGRAM_OPS_BOT_TOKEN",        },      },    },  },}

بهذا الإعداد، ينشر حساب Telegram ‏ops-bot موافقات التنفيذ المعاد توجيهها في الموضوع 77 من المحادثة -1001234567890. يستخدم الهدف الذي لا يحتوي على accountId الحساب الافتراضي للقناة، وينشر الهدف الذي لا يحتوي على threadId إلى الوجهة ذات المستوى الأعلى.

عندما تُرسل الموافقات إلى جلسة، هل يمكن لأي شخص في تلك الجلسة الموافقة عليها؟

لا. يتحكم التسليم إلى الجلسة فقط في مكان ظهور المطالبة. ولا يمنح بحد ذاته كل مشارك في تلك المحادثة صلاحية الموافقة.

بالنسبة إلى /approve العامة ضمن المحادثة نفسها، يجب أن يكون المُرسِل مخولًا مسبقًا بتنفيذ الأوامر في جلسة القناة تلك. وإذا كانت القناة تعرض معتمدين صريحين للموافقات، فيمكن لهؤلاء المعتمدين تخويل إجراء /approve حتى إن لم يكونوا مخولين بتنفيذ الأوامر في تلك الجلسة بخلاف ذلك.

تفرض بعض القنوات قيودًا أشد. تستخدم رسائل الموافقة الخاصة الأصلية في Discord وTelegram وMatrix وSlack، وعملاء الموافقة الأصليون المشابهون، قوائم المعتمدين التي جرى تحديدها لتخويل الموافقة. على سبيل المثال، قد تكون مطالبة الموافقة في موضوع منتدى على Telegram مرئية للجميع في الموضوع، لكن لا يمكن الموافقة عليها أو رفضها إلا بواسطة معرّفات مستخدمي Telegram الرقمية المحددة من channels.telegram.execApprovals.approvers أو commands.ownerAllowFrom.

ذو صلة

• موافقات التنفيذ — السياسة الأساسية ومسار الموافقة
• أداة التنفيذ
• الوضع ذو الصلاحيات المرتفعة
• Skills — سلوك السماح التلقائي المدعوم بالمهارات