فشل إعادة المصادقة OAuth على مستوى المثيل (Instance-level) مع خطأ invalid_target في n8n 2.29.7؛ يعمل على الإصدارات السابقة

أسئلة
1

وصف المشكلة/الخطأ/السؤال

يبدو أن إعادة مصادقة MCP OAuth على مستوى المثيل تتراجع في n8n 2.29.7.
بعد ترقية مثيل n8n الذي يستضيفه بنفسك إلى 2.29.7، فشلت إعادة مصادقة MCP OAuth البعيدة لموصلات الويب الخاصة بـ OpenAI/ChatGPT و Claude مع invalid_target / Invalid resource indicator.
نفس اسم مضيف MCP، وطريق Cloudflare، والعملاء البعيدين يعملون مرة أخرى على الفور عند التبديل إلى نسخة n8n أقدم. يستمر الوصول المحلي إلى MCP أيضًا في العمل، لذا يبدو أن هذا محدد لمسار OAuth authorize/resource-indicator البعيد في 2.29.7 بدلاً من انقطاع MCP عام.

ما رسالة الخطأ (إن وجدت)؟

{“error”:“invalid_target”,“error_description”:“Invalid resource indicator”}

يرجى مشاركة سير عملك

ليس محددًا لسير العمل. هذا هو MCP على مستوى المثيل / إعادة مصادقة OAuth، وليس مشكلة تنفيذ سير العمل.

معلومات عن إعداد n8n الخاص بك

إصدار n8n: 2.29.7 يفشل. نسخة Proxmox LXC الأقدم من 2.x تعمل مع نفس إعداد MCP البعيد.
قاعدة البيانات: على الأرجح إعداد البرامج النصية المجتمعية الافتراضية / SQLite. غير مؤكد بنسبة 100٪.
n8n EXECUTIONS_PROCESS / EXECUTIONS_MODE: الوضع الافتراضي/single-main-process، وليس وضع قائمة الانتظار.
تشغيل n8n عبر: Proxmox LXC المستضاف ذاتيًا، مثبت/تم إدارته من خلال مساعد Proxmox n8n الخاص بالمجتمع، يعمل كخدمة systemd.
نظام التشغيل: Debian GNU/Linux في Proxmox LXC.
الوكيل العكسي/الشبكة: نفق Cloudflare / WAF Cloudflare في المقدمة. اسم المضيف الرئيسي لـ n8n واسم مضيف MCP منفصلان؛ يوجه اسم مضيف MCP إلى نفس خلفية n8n.
يتم تفعيل MCP على مستوى المثيل.

تفاصيل إضافية / خطوات إعادة الإنتاج

الخطوات المختبرة:

  1. قم بتشغيل n8n 2.29.7 مع تفعيل MCP على مستوى المثيل.
  2. قم بتعريض طريق MCP OAuth من خلال اسم مضيف منفصل، على سبيل المثال n8n-mcp.[domain].
  3. حاول إعادة الاتصال/إعادة مصادقة موصل MCP البعيد الخاص بـ OpenAI/ChatGPT.
  4. يفشل مع:
    {“error”:“invalid_target”,“error_description”:“Invalid resource indicator”}
  5. حاول إعادة الاتصال/إعادة مصادقة موصل MCP البعيد الخاص بـ Claude.
  6. يفشل مع نفس الخطأ.
  7. تُظهر قياس البيانات الوصفية لـ Cloudflare أن الطلب تم نقله إلى n8n، وليس محجوبًا.
  8. اكتشاف الموارد المحمية لـ /mcp-server/http يعيد المورد المتوقع.
  9. يستمر الوصول المحلي إلى MCP في العمل.
  10. توقف المثيل 2.29.7 وابدأ نسخة n8n أقدم باستخدام نفس الطريق.
  11. يعيد الاتصال الخاص بـ OpenAI/ChatGPT و Claude بنجاح، ويعمل قراءة MCP البعيدة مرة أخرى.
    النتيجة المتوقعة:
    جب أن تكتمل إعادة مصادقة MCP OAuth البعيدة بنجاح لكل من OpenAI/ChatGPT و Claude، كما هو الحال في النسخة الأقدم من n8n.
    النتيجة الفعلية:
    يرفض n8n 2.29.7 طلب OAuth authorize مع invalid_target / Invalid resource indicator.
    الفرضية:
    قد يكون هذا انحدارًا في التحقق من صحة الموارد المحمية / مؤشر الموارد على مستوى المثيل في 2.29.7، وربما عندما يكون اسم مضيف MCP OAuth بديلاً منفصلاً عن اسم مضيف n8n الرئيسي.
2

شكراً @Andyp27، لقد أنشأت ADO-5561 كتذكرة تطوير داخلية لإصلاح هذا

3

هذا الخطأ هو التحقق من مؤشر الموارد RFC 8707، وفرضيتك حول “الاسم المستعار المنفصل” صحيحة جداً. يبدو أن 2.29.7 شدّد الشروط بحيث يتطلب تطابقاً دقيقاً: عندما يرسل ChatGPT/Claude معامل الموارد، يتم مقارنته مع عنوان URL الموارد الأساسي في n8n. إذا تم تقديم MCP على n8n-mcp.domain لكن N8N_EDITOR_BASE_URL / WEBHOOK_URL لا تزال تشير إلى اسم المضيف الرئيسي، فلن تتطابق وستحصل على invalid_target.

حل بديل يستحق المحاولة قبل وصول الإصلاح: اجعلها متطابقة. وجّه عنوان URL الأساسي لـ n8n إلى اسم مضيف MCP الذي يتصل به العملاء بالضبط، وتأكد من أن قيمة الموارد في وثيقة protected-resource في /.well-known تتطابق حرفياً (المخطط، المضيف، بدون شرطة مائلة عائمة).

5

لماذا يختلف اسم المضيف الرئيسي عن اسم مضيف MCP؟ أحاول فهم السبب وراء ذلك قبل محاولة إصلاحه.

6

مرحباً سيد وريكاردو،

شكراً على الردود والسرعة، سيد - هذا بالضبط المجال الذي اشتبهت فيه بعد الاختبار.

السبب في اختلاف اسم المضيف الرئيسي واسم مضيف MCP هو فصل متعمد لحدود الثقة.

في إعدادي:

  • n8n.[domain] هي واجهة المستخدم الرئيسية للإنسان/المسؤول.
  • n8n-mcp.[domain] مخصصة فقط لعملاء MCP البعيدين مثل ChatGPT/OpenAI و Claude.

اسم المضيف الرئيسي n8n محمي بواسطة Cloudflare Zero Trust / Access. يعمل هذا بشكل جيد لواجهة المتصفح والأدوات المحلية المراقبة، لكنه لا يعمل بشكل نظيف لعملاء MCP البعيدين أثناء OAuth/إعادة المصادقة، لأن العملاء يحتاجون للوصول مباشرة إلى نقاط نهاية MCP/OAuth الخاصة بـ n8n ولا يمكنهم إكمال أو تنفيذ تدفق Cloudflare Access بنفس الطريقة التي يمكن لجلسة متصفح بشرية.

لذا فإن اسم المضيف المنفصل MCP موجود لتجنب كشف واجهة المستخدم الرئيسية مع السماح برفع OAuth الخاص بـ MCP بالعمل. اسم مضيف MCP ليس مفتوحاً بنفس الطريقة مثل واجهة المستخدم. يتم قفله باستخدام قواعد Cloudflare WAF ذات الرفض الافتراضي بحيث يُسمح فقط بمسارات MCP/OAuth ذات الصلة لاستدعاءات وكيل AI، على سبيل المثال /mcp-server و /mcp-oauth و /.well-known و /oauth/consent والمسارات الأمامية/الثابتة الأدنى من n8n المطلوبة لتدفق موافقة OAuth. كل شيء آخر، بما في ذلك سطح واجهة المستخدم العادي ومسارات API/webhook وما إلى ذلك، يتم حظره في اسم مضيف MCP.

لذا فإن النية هي:

  • اسم مضيف واجهة المستخدم الرئيسية: محمي بواسطة Cloudflare Access / Zero Trust.
  • اسم مضيف MCP: باب MCP/OAuth العام الضيق، محمي بواسطة OAuth من n8n بالإضافة إلى قائمة السماح بمسار Cloudflare WAF.

هذا الفصل عمل في إصدار n8n السابق. بعد الترقية إلى 2.29.7، يفشل نفس الإعداد مع invalid_target / مؤشر مورد غير صالح لكل من إعادة مصادقة OpenAI و Claude البعيدة. يؤدي الرجوع إلى نسخة n8n السابقة، مع نفس إعداد DNS/WAF/العميل، إلى عمل كلا الموصلات البعيدة مرة أخرى.

يجعل شرحك معنى: إذا كانت 2.29.7 الآن تتحقق من مؤشر المورد RFC 8707 مقابل عنوان URL الأساسي الذي تم إنشاؤه من N8N_EDITOR_BASE_URL / WEBHOOK_URL، فإن اسم مضيف MCP المنفصل لن يطابق أياً منهما وسيتم رفضه.

قد يثبت حل بديل من جعل عنوان URL الأساسي متطابقاً مع اسم مضيف MCP السبب، ويمكنني اختباره على نسخة مرحلية. لكن بالنسبة للإنتاج فإنه ليس مثالياً، لأن تعيين عنوان URL الأساسي العام لـ n8n إلى اسم مضيف MCP سيجعل اسم مضيف MCP بشكل فعال اسم المضيف الأساسي/webhook لواجهة المستخدم أيضاً، مما يهزم سبب فصل حد الثقة لواجهة المستخدم عن حد الثقة MCP/OAuth.

الإصلاح المثالي، من وجهة نظري، سيكون أحد الخيارات التالية:

  1. السماح بتكوين عنوان URL أساسي/مورد منفصل عام لـ MCP/OAuth، مختلف عن N8N_EDITOR_BASE_URL / WEBHOOK_URL.
  2. إنشاء/التحقق من بيانات المورد المحمي MCP مقابل اسم مضيف MCP الفعلي المستخدم، على سبيل المثال Host / X-Forwarded-Host، حيث يكون آمناً.
  3. السماح بقائمة صريحة من مؤشرات المورد/أسماء مضيفات MCP الموثوقة لإعدادات وكيل عكسي موزعة ذاتياً.

أنا سعيد باختبار حل بديل مرحلي أو توفير رؤوس/محتوى الاكتشاف إذا كان مفيداً.

7

نعم، نفس المشكلة هنا وأريد أن أؤكد منطق Andyp27. لدينا أيضاً نطاق مختلف لعملاء MCP، لأن الوصول الأساسي / البشري الخاص بنا محمي بواسطة AWS Verified Access، لضمان أن المستخدمين الداخليين فقط يتمكنون من الوصول إلى نشر n8n الخاص بنا.

لدينا بوابة AWS API التي تسمح بالوصول إلى MCP، لكنها على نطاق مختلف وتقتصر على مسارات محددة.

8

شكراً على الرد التفصيلي وعلى مشاركة أفكارك بشأن الحلول المحتملة. سألقي نظرة على هذا وسأتعامل معه قريباً.

9

تحديث سريع: لدينا إصلاح جاهز. لكنه يتطلب تعيين متغير بيئة واحد، لذلك أريد أن أشرح السبب.

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

يضيف الإصلاح إعدادًا مخصصًا لحالتك بالضبط:

N8N_MCP_BASE_URL=https://n8n-mcp.

عند تعيينها، تتعامل n8n مع اسم المضيف هذا باعتباره عنوان URL عام كنسخة أصلية لخادم MCP: يتم الإعلان عنها في الاكتشاف، وقبولها كمؤشر موارد RFC 8707، واستخدامها كجمهور الرمز. يبقى N8N_EDITOR_BASE_URL و webhook URLs دون تغيير، لذا يتم الحفاظ على فصل حد الثقة الذي وصفته، والعملاء الذين يتصلون عبر اسم المضيف الرئيسي يستمرون في العمل أيضًا.

11

شكراً لك يا ريكاردو، هذه أخبار رائعة وستعمل بشكل جيد.

أقدّر جهودك واهتمامك في الحصول على متغير البيئة الجديد لـ MCP بعنوان URL منفصل.

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