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

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

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

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

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

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

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

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

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

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

ظهر المستودع للمرة الأولى في 29 June 2026، واعتباراً من 1 August 2026، فإن أحدث إصدار موسوم هو v1.3.3، وقد نُشر في 30 July 2026 ويحمل أيضاً الوسم latest. وينشر السجل أيضاً الوسم tip، المبني من أحدث commit على main.

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

نشر Open Connector خلف TLS على VPS تملكه

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

• Docker مع إضافة 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 من المضيف نفسه.

يحدد :? أن كل متغير مطلوب، لذلك يرفض المكدس البدء عند غياب .env بدلاً من البدء ببيانات اعتماد غير مشفّرة. ويُعد إبقاء القيم في .env بدلاً من ملف compose هو الأسلوب الموضح في ملفات البيئة والأسرار في Docker Compose.

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 أن تعيين المنفذ لا يزال هو التعيين الوارد من المشروع الأصلي، وأن البوابة تستجيب مباشرة للإنترنت بالكامل. يعني ظهور Connection refused في فحص الصحة أن الحاوية لا تستمع بعد، لذلك اقرأ السجلات قبل تعديل الـproxy.

    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"

لماذا يفرض OAuth استخدام اسم مضيف حقيقي

OOMOL_CONNECT_ORIGIN هو الإعداد الذي يتجاوزه كثيرون، ويؤدي تجاوزه إلى تعطيل OAuth بطريقة تبدو كأنها خلل في المزوّد. ينشئ runtime عنوان URI لإعادة التوجيه من هذا الأصل، بالصيغة <origin>/oauth/callback. عند تركه دون ضبط، يصبح الأصل افتراضياً http://localhost:3000، ولذلك يرسل runtime إلى المزوّد عنوان 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 هذا، ولذلك يجب أن يكون عنواناً يمكن للعالم الخارجي الوصول إليه. كما يرفض المزوّدون استخدام http:// لأي شيء باستثناء localhost. وهذا هو السبب الكامل الذي يجعل هذا النشر يحتاج إلى اسم مضيف وشهادة. اضبط الأصل قبل التشغيل الأول، لأن القيمة تُقرأ عند بدء التشغيل. بعد تعديل .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 بدلاً من أداة واحدة لكل واجهة برمجية، ما يحافظ على صغر قائمة أدوات الوكيل. يشرح تشغيل خوادم MCP على VPS جانب العميل من هذا الربط.

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

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

تشكّل بوابة تضم ألف موفّر خلفها سطحاً واسعاً تمنحه لنموذج لغوي. ويتسع هذا السطح فور أن يبدأ النموذج في قراءة نص لم يكتبه، لأن صفحة يعرضها مثيل 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، فنعم عملياً. يعيد المزوّد توجيه المتصفح إلى عنوان URL الخاص بالاستدعاء، لذلك يجب أن يكون هذا العنوان قابلاً للوصول من الإنترنت العام، كما يرفض المزوّدون استخدام http:// العادي خارج localhost. عيّن OOMOL_CONNECT_ORIGIN إلى اسم مضيف https:// قبل التشغيل الأول، وسجّل <origin>/oauth/callback في تطبيق OAuth لدى المزوّد.

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

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

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

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

هل ينبغي أن تكون البوابة قابلة للوصول من الإنترنت العام؟

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

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

ترخيصه Apache 2.0 ويتطور بسرعة: ظهر المستودع في 29 June 2026، وأُصدرت v1.3.3 في 30 July 2026، لذلك اعتبر كل رقم إصدار في هذا الدليل لقطة من 1 August 2026. شغّله باستخدام وسم إصدار محدد، وليس على latest أو tip، واقرأ ملاحظات الإصدار قبل كل ترقية، واحتفظ بنسخة احتياطية من volume سبق أن اختبرت استعادتها مرة واحدة. التصميم سليم لخادم تملكه، والمخاطرة تكمن في تغير الإصدارات، لا في البنية.