Webhook لا يستقبل طلبات من Google Chat API (يعمل بشكل صحيح عند الاستدعاء المباشر عبر HTTP)

أسئلة
1

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

لدي سير عمل منشور يستخدم عقدة Webhook (مُعدّة باستخدام
“Respond: Using Respond to Webhook Node”) وتعمل كواجهة خلفية
لتطبيق Google Chat.
المشكلة:

  • عندما أرسل طلب POST إلى عنوان URL الخاص بي في الإنتاج يدويًا
    (عبر PowerShell/Invoke-RestMethod)، يعمل بشكل مثالي: يظهر
    التنفيذ في علامة التبويب Executions، ويتم تشغيله بنجاح، ويعيد
    استجابة صحيحة.
  • عندما يرسل Google Chat رسالة إلى نفس عنوان URL للـ webhook
    (المُعدّ في Google Cloud Console > Google Chat API >
    Configuration > HTTP endpoint URL)، لا يتم إنشاء أي تنفيذ
    في علامة التبويب Executions في n8n.
  • من جانب Google، يُظهر Google Cloud Logging هذه الأخطاء عند
    محاولة تسليم الرسالة:
    • الرمز 3: “Can’t post a reply. The Chat app didn’t respond or its
      response was invalid.”
    • الرمز 13: “Due to an internal error, Chat failed to process the
      bot response”
      هذا يشير إلى أن الطلب من خوادم Google Chat لا يصل إلى سير العمل
      الخاص بي على الإطلاق (لا يوجد تنفيذ مسجل)، في حين أن الطلبات
      المتطابقة من مصادر أخرى تصل إليه بدون مشاكل.
      الأسئلة:
  1. هل هناك أي تصفية على مستوى Cloudflare/WAF على البنية الأساسية
    المشتركة لـ webhook في n8n Cloud قد تحجب أو ترفض الطلبات
    المحددة من خوادم Google Chat API؟
  2. هل هناك طريقة لرؤية السجلات على مستوى الحافة (قبل تنفيذ سير
    العمل) للتأكد من ما إذا كان الطلب يتم رفضه قبل الوصول إلى
    سير العمل الخاص بي؟
    شكرًا على مساعدتك!

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

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

(حدّد العقد على لوحتك واستخدم اختصارات لوحة المفاتيح CMD+C/CTRL+C و CMD+V/CTRL+V لنسخ ولصق سير العمل.)

شارك المخرجات المعادة من قبل العقدة الأخيرة

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

  • إصدار n8n:
  • قاعدة البيانات (الافتراضي: SQLite):
  • إعداد n8n EXECUTIONS_PROCESS (الافتراضي: own, main):
  • تشغيل n8n عبر (Docker, npm, n8n cloud, تطبيق سطح المكتب):
  • نظام التشغيل:
2

مرحباً @Octa-004 أهلاً وسهلاً!
هذا على الأرجح مشكلة في المصادقة بعقدة Webhook الخاصة بك، وليس حجباً من Edge أو Cloudflare. يوقّع Google Chat كل طلب برمز Authorization الخاص به: Authorization: Bearer <JWT> (صادر من chat@system.gserviceaccount.com، User-Agent Google-Dynamite)، لذلك لا يمكنه حمل أي بيانات اعتماد يتوقعها webhook الخاص بك. عندما تكون مصادقة Header أو Basic أو JWT مفعّلة على عقدة Webhook، يرفض n8n أي طلب لا يطابق رمزه ولا ينشئ تنفيذاً أبداً، وهذا بالضبط السبب في نجاح استدعاء PowerShell الخاص بك برمز البيانات الاعتماديّة الصحيح، بينما لا ينجح Google Chat، وتسجل Google “لم ترد أو كانت الاستجابة غير صالحة”.
عيّن مصادقة عقدة Webhook على None وأعد النشر؛ ستصل طلبات Google بعد ذلك إلى سير العمل وتسجل عمليات التنفيذ. للبقاء آمناً دون مصادقة على مستوى n8n، تحقق من رمز JWT الخاص بـ Google داخل سير العمل بدلاً من ذلك: عقدة Code تتحقق من المُصدِر chat@system.gserviceaccount.com والجمهور المقصود (رقم مشروع تطبيقك أو عنوان URL للنقطة النهائية)، مع حذف أي شيء يفشل في الاختبار.
بخصوص سؤاليك: n8n Cloud لا تحجب خوادم Google بشكل انتقائي هنا، وسجلات edge قبل التنفيذ لا تُكشف للمستخدمين، لذلك هذا عرض مخصص للدعم الفني فقط. أنت لا تحتاجها، لأن إيقاف المصادقة وإعادة الاختبار يؤكد السبب في خطوة واحدة.
بمجرد أن ينجح التسليم، تأكد من أن عقدة Respond to Webhook ترجع JSON صحيح من Chat مثل {"text":"..."} بسرعة، حتى لا تواجه رمز خطأ 3 لاستجابة غير صالحة حقاً.
Verify requests from Google Chat  |  Google for Developers

3

تشخيص جيد من @Anshul_Namdev — عدم تطابق المصادقة هو بالضبط السبب في أن استدعاء PowerShell اليدوي ينشئ عملية تنفيذ بينما Google Chat لا يفعل ذلك أبداً. يوقّع Google كل طلب باستخدام Bearer JWT الخاص به، لذا فإن أي مصادقة Header/Basic/JWT على عقدة Webhook ترفضها قبل إنشاء أي عملية تنفيذ.

الجزء الذي يستحق الإضافة: بمجرد تعيين مصادقة عقدة Webhook على “None” للسماح لـ Chat بالمرور، لا تريد ترك نقطة النهاية مفتوحة على مصراعيها. تحقق من توكن Google الخاص به داخل سير العمل بدلاً من ذلك. أسقط عقدة Code (أو IF) مباشرة بعد Webhook وتحقق من Bearer JWT للمصادقة الواردة:

  • يجب أن يكون المُصدر (iss) حساب خدمة نظام Google Chat (chat@system.gserviceaccount، الحساب الذي يوقّع طلبات Chat)
  • يجب أن تساوي الجمهور (aud) رقم مشروعك الرقمي لتطبيق Chat
  • تحقق من التوقيع مقابل شهادات x509 المنشورة من Google لنفس حساب الخدمة

إذا فشل أي فحص، أوقف سير العمل. فقط حركة Google Chat الأصلية تحمل توكناً يمر، لذا تبقى عقدة Webhook مفتوحة (طلبات Chat أخيراً تنشئ عمليات تنفيذ) بينما المتصلون العشوائيون يتم تصفيتهم. هذا يوفر لك نفس الحماية التي حاولت توفيرها مصادقة العقدة، دون حجب المرسل بالذات الذي تريده.

4

نفس المشكلة هنا على n8n 2.2.4 الذي يعمل على خادم خاص، والشرح حول المصادقة لا ينطبق على حالتي.

المشكلة

  • إرسال POST يدويًا إلى عنوان URL الخاص بي للـ webhook في بيئة الإنتاج (curl أو PowerShell) يعمل: تظهر عملية التنفيذ وتعمل وترجع الاستجابة المتوقعة. HTTP 200.
  • إرسال Google Chat إلى نفس عنوان URL لا ينشئ أي عملية تنفيذ. كل عملية تنفيذ قام بها هذا الـ webhook لديها اسم مستخدم الوكيل curl/8.5.0 أو PowerShell. لم تظهر أي طلب من Google قط، بما في ذلك الطلب الفاشل.
  • سجل Google Cloud: الرمز 13، “نظرًا لحدوث خطأ داخلي، فشل Chat في معالجة استجابة الروبوت”، 18 إدخالًا.
  • المصادقة على عقدة الـ webhook ليست السبب. الطلبات اليدوية الخاصة بي لا تُرسل رؤوس Authorization على الإطلاق وتعود بـ 200، لذا لا تفرض العقدة أي بيانات اعتماد. سير العمل لا يحدد المصادقة — العقدة هي ببساطة:

{ “httpMethod”: “POST”, “path”: “my-path”, “responseMode”: “responseNode”, “options”: {} }

typeVersion: 2، بدون مفتاح مصادقة. الاستجابة إلى الـ Webhook هي respondWith: json تُرجع غلاف hostAppDataAction.chatDataAction.createMessageAction.

تم التحقق منها بالفعل

  • تم التحقق من عنوان URL للنقطة النهائية حرفًا بحرف في وحدة تحكم Chat API، /webhook/ وليس /webhook-test/.
  • “Build as a Workspace add-on” محدد، حالة التطبيق LIVE، الميزات التفاعلية قيد التشغيل، عنوان URL للنقطة النهائية المشتركة HTTP لجميع المشغلات.
  • ثلاثة إعادات بناء من الصفر لتطبيق Chat في ثلاثة مشاريع Google Cloud جديدة. نفس النتيجة في كل مرة.

الأسئلة

  1. على n8n الذي يعمل على خادم خاص، أين يظهر الطلب الذي يصل إلى العملية لكنه لا ينشئ عملية تنفيذ قط؟ هل يسجل N8N_LOG_LEVEL=debug طلب POST إلى مسار غير مسجل، أم أن هناك طريقة أخرى للتأكد من الاستقبال؟ التمييز بين “Google لم تُرسل أبدًا” و"n8n أسقطتها قبل التنفيذ" هو العائق.
  2. هل يمكن لمسار webhook في بيئة الإنتاج أن يفشل في التسجيل بينما سير العمل نشط وعنوان URL يرجع 200 إلى الاستدعاءات اليدوية — بعد الاستيراد أو تكرار سير العمل؟ تم استيراد هذا عبر REST API ويحمل سلسلة webhookId قابلة للقراءة من قبل الإنسان بدلاً من UUID.
  3. في وحدة تحكم Chat API، حقل Service Account Email لا يُعرض على الإطلاق لهذا التطبيق — غائب وليس فارغًا، وبدون أي سلسلة gsuiteaddons في أي مكان في الصفحة. هل رأى أحد ذلك من قبل، وهل يشير إلى عدم تسجيل نشر الوظيفة الإضافية لهدف الإرسال قط؟
5

بما أن @JGCoder أكّد أن عقدة Webhook لا تستخدم أي مصادقة وأن طلب POST يدوي بدون مصادقة يعمل، فسأقسم التشخيص قبل تغيير إعدادات JWT:

  1. تحقق من سجل الوصول للوكيل العكسي/Ingress أثناء إرسال حدث اختبار Google Chat. إذا لم يظهر أي طلب من Google، فالخلل يكون قبل n8n: تحقق من عنوان URL الدقيق للإنتاج لتطبيق Chat وطريقة POST والنشر/التوفر والوصول للمستخدم الاختباري.
  2. إذا ظهر الطلب مع 30x أو 403، صحّح إعادة التوجيه أو WAF أو قاعدة TLS/proxy.
  3. إذا وصل إلى n8n لكن لم ينشئ أي تنفيذ، تحقق من تسجيل webhook المنشور بالإضافة إلى المسار الدقيق والطريقة.

للاختبار الواحد، قلّل سير العمل إلى Webhook (POST, production URL) -> Respond to Webhook وأرجع HTTP 200 خلال بضع ثوان مع {"text":"ok"}. ثم قارن عنوان URL والحالة المعروضة في Google Cloud Logging مع سجل الوكيل. هذا يحدد ما إذا كان الخلل في تسليم Google Chat أو الحافة/الوكيل أو n8n نفسه.