بقلم Matt Connor 2026-11-09

كيف تستضيف Open Connector ذاتياً لوكلاء الذكاء الاصطناعي

تعلم كيفية استضافة بوابة Open Connector على خادمك الخاص لحماية رموز OAuth من وكلاء الذكاء الاصطناعي. احصل على دليل إعداد الحاوية، وتكوين TLS، وإدارة النسخ الاحتياطي لـ SQLite.

ما الذي يقدّمه Open Connector لوكيل الذكاء الاصطناعي

يضع الاستضافة الذاتية لـOpen Connector بوابة مصادقة واحدة بين وكلاء الذكاء الاصطناعي لديك وكل واجهة API للبرمجيات كخدمة (SaaS) يستدعيها الوكيل، لذلك لا يحتفظ الوكيل أبداً برمز مزوّد الخدمة. وهي بوابة متاحة المصدر من OOMOL Lab، ومرخّصة حالياً بموجب ترخيص Apache 2.0 معدّل مع شروط إضافية. تظل الإصدارات حتى v1.9.4 خاضعة لترخيص Apache 2.0؛ وقد قدّم الإصدار v1.9.5 هذا التغيير. ويتطلب توفير خدمة مستضافة أو مُدارة تكون وظيفتها الأساسية هي وظائف OpenConnector ترخيصاً تجارياً من OOMOL. تعمل البوابة في حاوية واحدة، وتخزّن حالتها في ملف SQLite واحد، وتتيح إجراءات المزوّد عبر HTTP وعبر MCP (بروتوكول سياق النموذج).

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

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

يعلن الكتالوج عن أكثر من 1,000 مزوّد و10,000 إجراء مُعدّ مسبقاً، وهذه أرقام المشروع نفسه وليست أرقاماً يمكنك التحقق منها من الخارج. ما يمكنك التحقق منه هو البنية: نقطة نهاية HTTP واحدة لكل إجراء، واتصال مخزّن واحد لكل مزوّد، ورمز واحد لكل وكيل. إذا كان جانب الوكلاء لا يزال جديداً عليك، ولم تستقر بعد مصطلحات مثل استدعاء الأداة أو خادم MCP، فإن المسار التدريجي في كيفية تعلّم وكلاء الذكاء الاصطناعي من الصفر يشرح الحلقة والأدوات وعادات الأمان التي يفترضها هذا النوع من البوابات لديك مسبقاً.

لماذا تستضيف Open Connector ذاتياً بدلاً من استخدام خدمة موصل مستضافة

تؤدي خدمة الموصل المستضافة العمل نفسه، وتحتفظ برموز التحديث لكل موفر تربطه بها. رمز التحديث الخاص بـGoogle أو GitHub هو مفتاح طويل الأمد إلى بريدك ومستودعاتك. واختراقها يعني اختراقك. تنقل الاستضافة الذاتية هذه السجلات إلى SQLite على جهاز تستأجره وتديره، وتُحكم حمايتها بمفتاح لا يغادر جهازك أبداً.

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

ثبّت الإصدار قبل تثبيت أي شيء

Open Connector مشروع حديث. يثبت هذا الدليل الإصدار v1.3.3، المنشور في 30 July 2026، بوصفه لقطة التثبيت بتاريخ 1 August 2026. لم يعد هذا الإصدار أحدث إصدار. ينشر السجل أيضاً وسم tip، المبني من أحدث commit على main.

تتغير الوسوم المتحركة كثيراً في مشروع حديث إلى هذا الحد. يمكن لـdocker compose pull ينتقل عبر إصدارين أن يغيّر endpoint يعتمد عليه agent، وقد تقضي المساء في تصحيح المشكلة باعتبارها مشكلة في agent. ثبّت image على وسم إصدار، ثم رقِّه عندما تقرر ذلك، بعد قراءة ملاحظات الإصدار.

نشر Open Connector خلف TLS على VPS خاص بك

قبل بدء الحاوية، تحتاج إلى:

Docker Engine بإصدار 28.0.0 أو أحدث مع إضافة Compose، على Ubuntu 24.04 أو إصدار قريب منه
اسم مضيف يشير سجل A الخاص به إلى هذا الـVPS، مثل connect.example.com
Reverse Proxy ينهي TLS (أمان طبقة النقل) لهذا الاسم مسبقاً
سرّين عشوائيين، سننشئهما أدناه

يشرح Reverse Proxy باستخدام Traefik لعدة تطبيقات Docker Compose إعداد الـproxy. ويشرح دليل n8n على VPS باستخدام Docker وHTTPS إعداد الشهادة نفسه من البداية إلى النهاية لتطبيق واحد.

أنشئ السرّين أولاً. يحمي مفتاح التشفير بيانات الاعتماد المخزنة. ويحمي رمز المسؤول وحدة تحكم الويب وواجهة /api بالكامل. لا توجد قيمة افتراضية لأي منهما، وتبدأ بيئة التشغيل بشكل طبيعي من دونهما.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

انسخ القيمتين إلى مدير كلمات المرور الآن، قبل أول تشغيل. لا توجد طريقة لاسترداد مفتاح التشفير، وسبب ذلك مذكور في قائمة الأعطال أدناه.

أنشئ الآن compose.yaml. يختلف عن المثال الوارد من المشروع الأصلي في موضعين، وكلاهما مهم.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

التغيير الأول هو استخدام الوسم المثبّت بدلاً من latest. والتغيير الثاني هو المنفذ. ينشر الملف الوارد من المشروع الأصلي 3000:3000، ما يربطه بكل واجهات المضيف. يكتب Docker منافذه المنشورة في جدول NAT (ترجمة عناوين الشبكة) قبل أن ترى حزمة الشبكة سلسلة تصفية ufw، لذلك لا يغلق ufw deny 3000 ذلك المنفذ. هذا هو الفخ المشروح في سبب تجاوز منافذ Docker لـ ufw. يؤدي استخدام 127.0.0.1:3000:3000 إلى النشر على واجهة loopback فقط، ويتصل Reverse Proxy من المضيف نفسه. قبل Docker Engine 28.0.0، كان بإمكان المضيفين الموجودين في مقطع L2 نفسه الوصول إلى المنافذ المنشورة على localhost، ولذلك يتطلب هذا الدليل الإصدار 28.0.0 أو أحدث.

تجعل :? كل متغير مطلوباً، لذلك ترفض الحزمة البدء عند غياب .env بدلاً من البدء ببيانات اعتماد غير مشفّرة. إن إبقاء القيم في .env بدلاً من ملف compose هو النمط المشروح في ملفات البيئة والأسرار في Docker Compose. أبقِ /v1 و/mcp خاصين في Reverse Proxy إلى أن تنشئ رمز بيئة التشغيل الأول أدناه.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

يجيب /health عن { "ok": true } بعد بدء بيئة التشغيل. يجب أن يطبع ss القيمة 127.0.0.1:3000. يعني السطر الذي يقرأ 0.0.0.0:3000 أن المستمع مرتبط بكل واجهة IPv4، لكنه لا يثبت إمكانية الوصول من الإنترنت: فقد تمنع جدران الحماية في المنبع أو القواعد في سلسلة DOCKER-USER الخاصة بـDocker حركة المرور الخارجية. يعني ظهور Connection refused في فحص الصحة أن الحاوية لا تستمع بعد، لذلك اقرأ السجلات قبل تعديل الـproxy.

تسميات Traefik للخدمة نفسها

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

عندما يعمل Traefik داخل Docker على المضيف نفسه، أضف هذه الخدمة إلى شبكة Traefik واحذف كتلة ports:، لأن Traefik يصل إلى الحاوية عبر الشبكة الداخلية ولا حاجة إلى نشر أي منفذ على المضيف. يجب أن يطابق certresolver=le اسم المحلّل في إعداد Traefik الثابت، وإلا سيبدأ الموجّه من دون شهادة.

سبب حاجة عمليات استدعاء OAuth إلى الأصل الصحيح

OOMOL_CONNECT_ORIGIN هو الإعداد الذي يتجاهله كثيرون، ويؤدي تجاهله إلى تعطيل OAuth بطريقة تبدو كأنها خلل لدى المزوّد. ينشئ وقت التشغيل URI إعادة التوجيه من هذا الأصل بالصيغة <origin>/oauth/callback. إذا لم تُعيّن الأصل، تكون قيمته الافتراضية http://localhost:3000، لذلك يرسل وقت التشغيل إلى المزوّد URI إعادة توجيه هو http://localhost:3000/oauth/callback، بينما سجّل تطبيق OAuth لديك القيمة https://connect.example.com/oauth/callback. تختلف السلسلتان، لذلك يجيب GitHub:

The redirect_uri MUST match the registered callback URL for this application.

يعيد مزوّد OAuth توجيه المتصفح إلى ذلك URI، لذلك يجب أن يكون العنوان قابلاً للوصول من المتصفح. لا يتطلب OAuth اسماً عاماً للمضيف في جميع الحالات؛ إذ توثّق OpenConnector عمليات استدعاء GitHub على العنوان http://localhost:3000/oauth/callback. يستخدم هذا النشر على VPS اسماً للمضيف وشهادة، لكي يصل المتصفح إلى البوابة عبر أصل HTTPS الخاص بها. عيّن الأصل قبل التشغيل الأول، لأن القيمة تُقرأ عند بدء التشغيل. بعد تعديل .env أو compose.yaml، شغّل docker compose up -d مرة أخرى لتطبيق التغيير.

اربط مزوّدك الأول عبر OAuth

أنشئ تطبيق OAuth لدى المزوّد أولاً. في GitHub، انتقل إلى Settings، ثم Developer settings، ثم OAuth Apps، ثم New OAuth App. اضبط عنوان URL لاستدعاء التفويض على https://connect.example.com/oauth/callback. احتفظ بمعرّف العميل وسرّ العميل.

يحمل كل استدعاء /api رمز المسؤول، لذا صدّره مرة واحدة لجلسة shell.

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

تعرض هذه القائمة عنوان URI لإعادة التوجيه الذي يتوقعه runtime لكل مزوّد. وهذا يجعلها أسرع طريقة للتحقق من أن origin استخدم القيمة الجديدة. إذا ظل يعرض localhost، فإن الحاوية تعمل بالقيمة القديمة، وسيفشل تدفق OAuth في الخطوة الأخيرة.

خزّن بيانات اعتماد العميل، ثم ابدأ عملية التفويض.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

يعيد الاستدعاء الثاني authorizationUrl. افتحه في متصفح، ووافق على النطاقات المطلوبة، ثم يعيد المزوّد المتصفح إلى /oauth/callback، حيث يستبدل runtime الرمز المميز ويخزّن بيانات الاعتماد. تعرض وحدة تحكم الويب على origin الخطوات نفسها باستخدام نموذج، مع الحماية نفسها بواسطة رمز المسؤول. أما المزوّدون الذين يستخدمون مفتاح API عادي، فيتجاوزون كل ذلك: يخزّن PUT /api/connections/<service> المفتاح مباشرةً باستخدام {"authType":"api_key","values":{"apiKey":"..."}}.

امنح كل وكيل رمزاً مميزاً لوقت التشغيل، ولا تمنحه بيانات الاعتماد

يصادق الوكيل على البوابة باستخدام رمز مميز لوقت التشغيل، وتُصدره واجهة الإدارة البرمجية.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

تحمل الاستجابة رمزاً مميزاً يبدأ بـ oct_. أصدر رمزاً واحداً لكل وكيل، وسمّه باسم ذلك الوكيل، لأن إلغاء رمز لا يمكنك تحديده يعني إلغاء جميع الرموز. بعد ذلك، يستدعي الوكيل الإجراءات عبر HTTP العادي.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

تكون الاستجابة السليمة غلافاً يكون الحقل success فيه هو true، بينما توجد حمولة المزوّد ضمن data. لا يظهر رمز GitHub المميز في هذه الاستجابة بأي موضع. بالنسبة إلى عميل MCP، وجّهه إلى https://connect.example.com/mcp مع ترويسة bearer نفسها، وستوفّر البوابة أدوات اكتشاف مثل search_actions وexecute_action بدلاً من أداة واحدة لكل API، ما يحافظ على صغر قائمة أدوات الوكيل. يشرح تشغيل خوادم MCP على VPS جانب العميل من هذا الربط.

أجرِ فحصاً إضافياً قبل اعتبار الإعداد مكتملاً. كرّر استدعاء الإجراء بعد حذف ترويسة authorization. يستدعي دليل البدء السريع الخاص بالمشروع /v1 من دون أي bearer، ولذلك فإن التثبيت الذي لم تُضبط فيه مصادقة وقت التشغيل سينفّذ الإجراءات لأي شخص يستطيع الوصول إلى المنفذ. إذا نجح الاستدعاء غير الموثّق، فلديك حلّان: اضبط رموز وقت التشغيل وتأكد من أن الاستدعاء المجهول يفشل الآن، أو قيّد /api و/v1 و/mcp في الـreverse proxy على العناوين التي تأتي منها وكلاؤك. يجب أن يكون /oauth/callback قابلاً للوصول من المتصفح الذي يُكمل التفويض، ولا يلزم أن يكون مفتوحاً أمام الإنترنت بالكامل.

قلّل قائمة الإجراءات إلى ما يحتاجه الوكيل

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

يقبل OOMOL_CONNECT_ALLOWED_ACTIONS قائمة سماح مفصولة بفواصل ويفهم service.* و*. أما OOMOL_CONNECT_BLOCKED_ACTIONS فهو قائمة المنع، وتكون الأولوية لقائمة المنع. يعني ضبط قائمة السماح على github.get_current_user,github.list_issues رفض كل إجراء آخر، بصرف النظر عما يطلبه الوكيل. وهذا هو الفرق بين الخطأ والحادث الأمني. تحمل رموز الوصول وقت التشغيل قواعد إجراءاتها الخاصة بالإضافة إلى القواعد العامة، وتبدأ قائمة allowedProxies فيها فارغة، لذلك يُرفض POST /v1/proxy/:service إلى أن تمنحه صراحةً. تعيد نقطة نهاية الوكيل هذه توجيه طلب خام إلى موفّر مع إرفاق بيانات اعتمادك، لذلك اتركها فارغة ما لم يحتج إليها وكيل محدد.

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

انسخ احتياطياً الخادم الذي يحتوي على جميع الرموز

هناك أمران مهمان، ولا يفيد أحدهما من دون الآخر. تحتوي قاعدة البيانات الموجودة في /app/data/connect.sqlite داخل وحدة التخزين connector-data على بيانات الاعتماد المختومة. ويفك مفتاح التشفير الموجود في .env ختمها. لا تستعيد نسخة وحدة التخزين الاحتياطية شيئاً من دون المفتاح، ولا يستعيد المفتاح شيئاً من دون وحدة التخزين. لذلك احفظ المفتاح في مدير كلمات المرور، وأدرج وحدة التخزين ضمن دورة النسخ الاحتياطي المعتادة.

أوقف الحاوية أثناء نسخ ملف SQLite، لأن النسخة التي تؤخذ أثناء عملية كتابة قد تُستعاد كقاعدة بيانات تالفة.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

اسم وحدة التخزين هو دليل مشروعك مضافاً إليه _connector-data. لذلك يظهر الأمر الأول هنا: الصق الاسم الفعلي في الأمر الثالث. أرسل الأرشيف خارج VPS باستخدام نسخ restic الاحتياطية من VPS، إذ يشفره قبل مغادرته، لأن هذا الأرشيف هو مخزن بيانات الاعتماد.

يحتفظ وقت التشغيل بآخر عمليات التشغيل كسجلات تدقيق، وعددها الافتراضي 5,000 سجل، كي تتمكن وحدة التحكم من إظهار الوكيل الذي شغّل كل عملية ووقت تشغيلها. اقرأ هذا السجل أولاً عندما يتصرف أحد الوكلاء بطريقة غير مألوفة. وجّه صفحة حالة Uptime Kuma إلى https://connect.example.com/health أيضاً. عندما تتوقف البوابة عن الاستجابة، تفشل الوكلاء بطرق مربكة، ومعرفة أن البوابة متوقفة توفر ساعة من قراءة مخرجات الوكلاء.

ما الذي يتعطل، والرسالة التي ستظهر

redirect_uri_mismatch لدى موفّر الخدمة. يختلف الأصل عن عنوان URL المسجّل لطلب الاستدعاء. قارن السلسلة النصية الدقيقة من /api/oauth/configs بإعدادات التطبيق لدى موفّر الخدمة، بما في ذلك https مقابل http وأي شرطة مائلة في النهاية.

يعيد كل استدعاء /api الرمز 401. رأس رمز المسؤول مفقود أو مكتوب بشكل غير صحيح. الرأس هو Authorization: Bearer <token>، وتطلب وحدة تحكم الويب الرمز نفسه.

تعمل الحاوية، وتبقى بيانات الاعتماد بنص واضح. يحدث ذلك عندما لا يصل OOMOL_CONNECT_ENCRYPTION_KEY إلى الحاوية، لأن بيئة التشغيل تخزّن سجلات بيانات الاعتماد دون تشفير بدلاً من رفض بدء التشغيل. أثبت ذلك على تثبيتك بنفسك: صِل موفّر خدمة باستخدام مفتاح API يمكنك تمييزه، ثم ابحث عنه في قاعدة البيانات.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

تعني قيمة أكبر من 0 أن المفتاح غير مطبّق. لذلك تحقّق من وجود .env في الدليل نفسه الذي يوجد فيه compose.yaml، ومن أن docker compose config يعرض القيمة. بعد ضبط المفتاح، يعيد البحث نفسه القيمة 0، لأن السجل مختوم باستخدام AES-256-GCM (معيار التشفير المتقدم، بمفتاح حجمه 256 بت، ووضع غالوا/العداد).

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

يحصل الوكيل على خطأ يذكر إجراءً يمكنه رؤيته في الفهرس. الاكتشاف والتنفيذ منفصلان. قد يظهر الإجراء في search_actions، ومع ذلك يرفضه OOMOL_CONNECT_ALLOWED_ACTIONS أو ترفضه قائمة المنع أو قواعد رمز بيئة التشغيل نفسه.

الترقيات. انسخ وحدة التخزين احتياطياً، وعدّل وسم الصورة إلى الإصدار الجديد، ثم docker compose pull && docker compose up -d. راقب docker compose logs -n 50 connector بحثاً عن سطر ترحيل، وأعد فحص السلامة وإجراءً فعلياً واحداً قبل الاعتماد عليه مجدداً. يعني الرجوع إلى إصدار سابق إعادة الوسم القديم، وهذا ينجح فقط لأنك ثبّتَّه.

FAQ

هل أحتاج إلى نطاق عام لاستضافة Open Connector ذاتياً؟

بالنسبة إلى المزوّدين الذين يستخدمون مفتاح API، لا. تكفي بوابة على 127.0.0.1. ولا يتطلب OAuth ذلك دائماً أيضاً؛ إذ توثّق OpenConnector عنوان الاستدعاء المحلي لـGitHub على أنه http://localhost:3000/oauth/callback. يجب أن يتمكن المتصفح الذي يكمل التفويض من الوصول إلى عنوان الاستدعاء. في عملية النشر هذه على VPS، عيّن OOMOL_CONNECT_ORIGIN إلى اسم مضيف https:// قبل التشغيل الأول، وسجّل <origin>/oauth/callback في تطبيق OAuth لدى المزوّد.

ماذا يحدث إذا فقدت مفتاح تشفير Open Connector؟

لا يمكن فك تشفير بيانات الاعتماد المخزنة، ولا توجد طريقة لاستردادها. لا يُخزَّن المفتاح عمداً بجانب البيانات، لذلك لا يستطيع أي شخص يملك قاعدة البيانات قراءته، بما في ذلك أنت. خيارك الوحيد هو تعيين مفتاح جديد وإعادة ربط كل مزوّد. احتفظ بالمفتاح في مدير كلمات مرور، وأدرج قاعدة البيانات في دورة النسخ الاحتياطي، لأن الاستعادة تحتاج إلى كليهما.

هل يستطيع وكيل الذكاء الاصطناعي لدي رؤية رمز وصول المزوّد؟

ليس عندما يستدعي الوكيل المزوّد عبر البوابة. يصادق الوكيل باستخدام رمز تشغيل يبدأ بـ oct_، وتُدرج البوابة بيانات اعتماد المزوّد في الطلب الصادر على الخادم، ثم تعيد الاستجابة فقط. هناك أمران يخرقان هذه الحماية: نقطة النهاية /v1/proxy/:service، التي تمرر الطلبات الخام مع إرفاق بيانات اعتمادك، وقد بدأت منحها فارغة لسبب؛ ولصق مفتاح API في الوكيل بنفسك، ما يتجاوز البوابة بالكامل.

هل ينبغي إتاحة الوصول إلى البوابة من الإنترنت العام؟

يجب أن يكون عنوان استدعاء OAuth متاحاً للمتصفح الذي يكمل التفويض، لكن ذلك لا يتطلب إتاحة الوصول من الإنترنت بأكمله. مع Docker Engine 28.0.0 أو إصدار أحدث، ومع استخدام شبكة bridge الافتراضية، انشر منفذ الحاوية على 127.0.0.1 لإبقاء المنفذ المنشور متاحاً من المضيف فقط، وضع الـreverse proxy أمامه. كانت إصدارات Docker الأقدم تسمح للمضيفين الموجودين على مقطع L2 نفسه بالوصول إلى المنافذ المنشورة على localhost. بعد ذلك، اختبر استدعاء إجراء واحداً من دون ترويسة authorization. إذا نجح، فقيّد /api و/v1 و/mcp في الـproxy على العناوين التي تستخدمها وكلاؤك، إلى أن تصبح الاستدعاءات المصادق عليها هي الاستدعاءات الوحيدة التي تعمل.

هل أصبح Open Connector جاهزاً للاستخدام في الإنتاج؟

تستخدم الإصدارات الحالية ترخيص Apache 2.0 معدّلاً مع شروط إضافية. وتظل الإصدارات حتى v1.9.4، بما في ذلك الإصدار المحدد v1.3.3، خاضعة لترخيص Apache 2.0. تتطلب خدمة موصّل مستضافة أو مُدارة تكون الوظيفة الأساسية فيها هي وظائف OpenConnector ترخيصاً تجارياً من OOMOL بموجب الترخيص الحالي. تظل أوامر تثبيت v1.3.3 لقطة تعود إلى 1 August 2026، وقد صدر ذلك الإصدار في 30 July 2026. شغّله باستخدام وسم إصدار محدد، وليس على latest أو tip، واقرأ ملاحظات الإصدار قبل كل ترقية، واحتفظ بنسخة احتياطية من الـvolume سبق أن اختبرت استعادتها مرة واحدة. التصميم مناسب لخادم تملكه، والمخاطرة تكمن في تغيّر الإصدارات، لا في البنية.

هل كان هذا المقال مفيدًا؟

#ai-agents#oauth#استضافة ذاتية#integrations#source-available