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

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

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

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

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

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

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

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

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

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

Open Connector مشروع حديث. ظهر المستودع لأول مرة في 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
• وكيل عكسي ينهي TLS (أمان طبقة النقل) لهذا الاسم
• سرّين عشوائيين، يُنشآن أدناه

يغطي وكيل Traefik العكسي لتطبيقات Docker Compose المتعددة جانب الوكيل. وتشرح 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 فقط، ويتصل الوكيل العكسي من المضيف نفسه.

تجعل :? كل متغير مطلوبًا، لذلك ترفض الحزمة البدء عند غياب .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 أن تعيين المنفذ ما زال هو تعيين المنبع، وأن البوابة تستجيب مباشرة للإنترنت بالكامل. تعني عبارة رفض الاتصال في فحص الصحة أن الحاوية لا تستمع بعد، لذا اقرأ السجلات قبل تعديل الوكيل.

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

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

توفّر البوابة التي تضم ألف موفّر خلفها نطاقًا واسعًا لنموذج اللغة. ويضيّق نطاقها ضابطان.

يتلقى 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 من إتاحته خارج جدار الحماية، وضع الوكيل العكسي أمامها. بعد ذلك اختبر استدعاء إجراء واحدًا من دون ترويسة authorization. إذا نجح، فقيّد /api و/v1 و/mcp في الوكيل بالعناوين التي تستخدمها وكلاؤك، إلى أن تصبح الاستدعاءات المصادق عليها هي الاستدعاءات الوحيدة التي تعمل.

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

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