طلب HTTP يرجع 401 "No valid key" بينما نفس الطلب يعمل في Postman

أسئلة
1

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

مرحباً بالجميع،
أواجه مشكلة غريبة مع طلب HTTP في n8n.
بيئة العمل
n8n Self Hosted 2.20.11
HTTP Request node v4.4
واجهة برمجية خارجية تستخدم مصادقة JWT Bearer
ما يحدث
أستدعي نقطة نهاية التفويض من n8n.
تُرجع الواجهة البرمجية رمز JWT صحيح.
أستخدم نفس الرمز بالضبط في عقدة HTTP Request ثانية.
ترد الواجهة البرمجية بـ:
{
“result”: “error”,
“description”: “No valid key”
}
حالة HTTP: 401
مهم
نفس الرمز المنسوخ يدويًا من n8n إلى Postman يعمل بشكل صحيح.
تحقق موفر الواجهة البرمجية من نقطة النهاية والبيانات الاعتمادية.
تم استيراد cURL المصدّر بالضبط من Postman في عقدة HTTP Request جديدة تماماً وفشل بالفعل في n8n.
تم اختبار خيار Lowercase Headers.
تم اختبار إعدادات Gzip / الضغط.
تم اختبار Accept-Encoding: identity.
يتم إرسال رأس Authorization كـ:
Authorization: Bearer
اختبر بائع الواجهة البرمجية نفس الطلب من Postman بنفس الرمز وتلقى:
{
“result”: “ok”,
“idlead”: “5”
}
هل رأى أحد حالة حيث يرسل n8n شيئاً مختلفاً عن Postman حتى عند استيراد cURL بالضبط؟
أي أفكار حول كيفية فحص الطلب الخارج الخام من n8n؟
شكراً.

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

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

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

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

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

@Hector_AnVa أسرع طريقة لمعرفة ما يرسله n8n بالضبط (كما طلبت تماماً): وجّه كليهما إلى مفتش الطلبات. احصل على عنوان webhook.site، عيّن عقدة n8n وطلب Postman الخاص بك للوصول إليها، شغّل كليهما، قارن رؤوس البيانات المُلتقطة. هذا دائماً ما يكشف الفرق.

لقد استبعدت مسألة حالة الأحرف والضغط، إذاً العاملان الشائعان الاثنان:

  • مصادقة Authorization مكررة. إذا كانت المصادقة في العقدة معيّنة على بيانات اعتماد AND وهناك أيضاً رأس Authorization يدوي (استيراد cURL غالباً ما يضيف واحداً)، يرسل n8n اثنين والـ API يرجع 401، احتفظ بواحد فقط.
  • رؤوس البيانات الافتراضية في n8n، تضيف User-Agent وأحياناً Accept-Encoding لا يضيفها Postman، والبوابات الصارمة ترفضها.

بما أن استيراد cURL نفسه فشل، رهاني على Authorization المكررة، الفرق في webhook.site يؤكده في 30 ثانية.

3

لرؤية بالضبط ما يرسله n8n، استخدم خدمة فحص الطلبات. هذه هي الطريقة الأكثر موثوقية لمقارنة طلب n8n مع طلب Postman.

  • استخدم Webhook.site:
    1. انتقل إلى Webhook.site وانسخ عنوان URL الفريد المقدم.
    2. غيّر عنوان URL لعقدة HTTP Request الثانية إلى عنوان Webhook.site هذا.
    3. نفّذ العقدة.
    4. افحص الرؤوس والجسم في واجهة Webhook.site.

ما يجب البحث عنه: تحقق مما إذا كان Authorization يتم ترميزه بشكل مزدوج، أو إذا كانت هناك مسافات بيضاء إضافية، أو إذا كان Content-Type مختلفًا عما يتوقعه واجهة برمجة التطبيقات الخاصة بك.

قد يضيف n8n في بعض الأحيان في “Authentication: Predefined Credential Type” رؤوسًا تتعارض مع رأس Authorization المضاف يدويًا. تأكد من عدم إرسالك بالصدفة لرأسي Authorization.

  • اختبار: اضبط قائمة المصادقة على “None” واستخدم بصرامة معامل رأس باسم Authorization بقيمة Bearer <TOKEN>.

إذا كنت تمرر الرمز المميز عبر تعبير (على سبيل المثال، {{ $json.token }}), تأكد من عدم وجود فواصل أسطر أو مسافات مخفية يتم التقاطها من العقدة السابقة. حاول قص الرمز: {{ $json.token.trim() }}.

تحظر بعض واجهات برمجة التطبيقات الطلبات بناءً على رأس User-Agent الافتراضي axios (غالبًا axios/x.x.x). حاول إضافة رأس User-Agent مخصص (على سبيل المثال، Mozilla/5.0...) لمحاكاة متصفح.

تأكد من تعيين رأس Accept بشكل صريح (على سبيل المثال، application/json)، حيث قد تتصرف بعض واجهات برمجة التطبيقات بشكل مختلف إذا تم إرسال */* الافتراضي.

4

بالإضافة إلى نصيحة @kjooleng حول Webhook.site: السبب الشائع جداً لهذا النمط بالذات (التوكن يعمل في Postman، لكن نفس التوكن يفشل في n8n) هو وجود مسافة غير مرئية أو فاصل سطر في نهاية التوكن، والذي يتم إدراجه عند النسخ من الاستجابة HTTP الأولى إلى n8n.

للتحقق بشكل محدد: في عقدة HTTP Request الأولى التي تُرجع JWT، افحص المخرجات بعناية، ويفضل عبر عقدة الكود باستخدام JSON.stringify($json.token) بدلاً من العرض العادي. إذا ظهر هناك "\n" أو مسافات إضافية في النهاية، فهذا هو السبب. Postman غالباً ما يقوم بالقص التلقائي عند الإدراج اليدوي، لكن n8n لا يفعل ذلك.

الحل إذاً هو استخدام .trim() على حقل التوكن قبل تمريره إلى الطلب الثاني، إما عبر عقدة كود أو مباشرة في حقل Expression: {{ $json.token.trim() }}.

5

@Hector_AnVa يمكنك تجربة Webhook.site، وجّه n8n و Postman إلى نفس الرابط وقارن ما يتم إرساله بالفعل.

السبب الأكثر احتمالاً: رأس Authorization مكرر. عند استيراد cURL، يضيف n8n أحياناً واحداً خاصاً به في الأعلى.

الحل: اضبط Authentication على “None” واستخدم فقط رأس Authorization: Bearer يدوي.

تحقق أيضاً من:

قص رمزك: {{ $json.token.trim() }} المسافات المخفية تكسر المصادقة

أضف User-Agent مخصص - القيمة الافتراضية لـ n8n (axios/x.x.x) يتم رفضها من قبل بعض APIs