Google OAuth redirect_uri_mismatch على مثيل staging — الإنتاج يعمل بدون مشاكل مع نفس تطبيق OAuth

أسئلة
,
1

<n8n version: 2.20.7
Database: SQLite (default)
Running via: Docker (self-hosted, Ubuntu 24.04 on DigitalOcean)
Reverse proxy: nginx with SSL via Certbot/Let’s Encrypt
المشكلة:
لدي مثيلا n8n بنفس الاستضافة الذاتية:
Production: n8n.revvittsystems.com — Gmail OAuth يعمل بشكل مثالي، بما في ذلك إنشاء بيانات اعتماد جديدة تماماً
Staging: staging.revvittsystems.com — Gmail OAuth يفشل مع Error 400: redirect_uri_mismatch في كل مرة
كلا المثيلين يشغل n8n 2.20.7 على Docker مع reverse proxy nginx. كلاهما يستخدم نفس تطبيق Google Cloud OAuth (نفس Client ID/Secret). حاولت أيضاً إنشاء عميل OAuth منفصل تماماً بـ redirect URI للـ staging فقط — نفس الخطأ.
ما أكدته:
رابط redirect URI المعروض في واجهة n8n staging هو https://staging.revvittsystems.com/rest/oauth2-credential/callback
هذا الرابط بالضبط مسجل في Google Cloud Console تحت Authorized redirect URIs
فككت رابط خطأ Google وأكدت أن redirect_uri الذي يرسله n8n هو https://staging.revvittsystems.com/rest/oauth2-credential/callback — يطابق بالضبط
تم تعيين X-Forwarded-Proto $scheme في nginx بحيث ينشئ n8n بشكل صحيح https://
تم نشر التطبيق للـ Production في شاشة موافقة Google OAuth
تم الاختبار في نافذة incognito — نفس الخطأ
إنشاء بيانات اعتماد جديدة على production يعمل فوراً — تطبيق Google OAuth نفسه بخير
إنشاء عميل OAuth جديد منفصل تماماً للـ staging يفشل أيضاً مع نفس الخطأ
ملف .env للـ Staging:
N8N_HOST=staging.revvittsystems.com
N8N_PORT=5678
N8N_PROTOCOL=https
WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com
GENERIC_TIMEZONE=America/New_York
إعدادات nginx للـ Staging:
server {
listen 443 ssl;
server_name staging.revvittsystems.com;
ssl_certificate /etc/letsencrypt/live/staging.revvittsystems.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/staging.revvittsystems.com/privkey.pem;
large_client_header_buffers 4 16k;
location / {
proxy_pass http://localhost:5678;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection ‘upgrade’;
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
proxy_buffer_size 16k;
proxy_buffers 4 16k;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
ملاحظة إضافية: عند تسجيل الدخول كحساب المالك/المسؤول على staging، النقر على “Sign in with Google” يعطي خطأ 414 URI Too Long بدلاً من ذلك (خطأ معروف في n8n حيث يتم إلحاق نطاقات المسؤول بالعنوان). إنشاء من حساب عضو غير مسؤول يتجاوز الخطأ 414 لكنه يصطدم بـ redirect_uri_mismatch.
السؤال: ما الذي يمكن أن يسبب redirect_uri_mismatch عندما يكون الرابط مؤكداً صحيحاً ويطابق بالضبط؟ هل هناك شيء محدد حول تدفق OAuth في n8n 2.20.7 قد يسبب هذا على مثيل جديد؟!-- مرحباً! أسرع طريقة للعثور على الحلول هي استخدام وظيفة :magnifying_glass_tilted_right: البحث في الأعلى يميناً.
إذا لم يتم طرح سؤالك من قبل، يرجى اتباع النموذج أدناه. تجاوز الأسئلة التي لا تنطبق عليك.
:brazil: :france: :south_korea: :germany: يمكنك النشر بأي لغة - سنترجم منشورك لك!
→

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

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

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

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

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

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

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

مرحباً @Sam_Rao، أهلاً وسهلاً!
أعتقد أن متغير البيئة n8n_proxy_hops لديك إما لم يتم تعيينه أو لم يتم تعيينه بشكل صحيح وفقاً لإعدادك، يجب أن يبدو متغير env هذا بالشكل التالي:

N8N_HOST=staging.revvittsystems.com
N8N_PORT=5678
N8N_PROTOCOL=https
N8N_PROXY_HOPS=1
WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com/
GENERIC_TIMEZONE=America/New_York

وتأكد من أن إعدادات Nginx لديك تحتوي على هذه الأشياء أيضاً:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;

أخبرني كيف سيسير الحال بعد إعادة التشغيل.

3

مرحباً @Sam_Rao

عدم تطابق معرّف إعادة التوجيه (Redirect URI) الذي تواجهه على مثيل المرحلة الإنتاجية لديك هو عقبة شائعة ومحبطة في عمليات نشر n8n. حتى عندما يبدو العنوان متطابقاً، فإن خوادم المصادقة في Google صارمة جداً. تتطلب العملية تطابقاً دقيقاً حرفياً بين القيمة المحددة في وحدة التحكم في Google Cloud والقيمة التي يرسلها n8n في طلبه. إذا كان هناك حتى اختلاف في حرف واحد، مثل شرطة مائلة نهائية مفقودة، فسيتم رفض المصادقة فوراً.

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

من الحيوي أيضاً التحقق من أن متغيرات البيئة داخل حاوية Docker الخاصة بك تطابق التوقعات. بينما يبدو ملف .env الخاص بك صحيحاً، من الممكن أن تكون عملية n8n المشغلة لها تكوين مختلف بسبب التخزين المؤقت أو طريقة تهيئة الحاوية. تنفيذ أمر لطباعة متغيرات البيئة من داخل الحاوية سيساعدك على التحقق من تطبيق إعدادات WEBHOOK_URL و N8N_PROTOCOL بشكل صحيح وعدم الرجوع إلى قيم داخلية غير صحيحة.

docker exec <container_id> env

يجب عليك أيضاً فحص تكوين Nginx الخاص بك بحثاً عن أي تضارب محتمل. بينما إعداداتك الحالية معيارية، تأكد من أن رؤوس مثل X-Forwarded-Proto و X-Forwarded-Host يتم تمريرها بشكل صحيح دون أن يتم الكتابة فوقها بواسطة خدمات أخرى. إذا كنت تستخدم طبقات إضافية مثل Cloudflare، تحقق من أنها لا تقوم بتعديل أو حذف هذه الرؤوس قبل وصولها إلى خادم Nginx العكسي الخاص بك، لأن هذا سيمنع n8n من إنشاء عنوان إعادة التوجيه الآمن الصحيح.

proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;

فيما يتعلق بإعداد وحدة التحكم في Google Cloud، تأكد من أن شاشة موافقة OAuth في مشروعك مكونة بشكل صحيح لبيئة المرحلة الإنتاجية. إذا كان تطبيقك حالياً في المرحلة الاختبارية، فيجب عليك إضافة أي حساب تستخدمه للاختبار بشكل صريح إلى قائمة “المستخدمون الاختبارية” في الوحدة. علاوة على ذلك، تأكد من أن إعدادات المشروع لا تحتوي على قيود المجال التي قد تجعل نطاق المرحلة الإنتاجية يتم التعامل معه بشكل مختلف عن بيئة الإنتاج الخاصة بك.

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

4

مرحبا Anshul!

شكراً على مساعدتك!

طبقت الإصلاحات المقترحة — لا أزال أحصل على redirect_uri_mismatch.

التغييرات التي تم إجراؤها:

  • أضفت N8N_PROXY_HOPS=1 إلى .env (تم التأكد منه داخل الحاوية عبر docker exec)

  • أضفت X-Forwarded-For و X-Forwarded-Host و X-Forwarded-Proto إلى nginx

  • أعدت تشغيل حاوية nginx و n8n معاً

يؤكد env الحاوية أن جميع المتغيرات صحيحة:

WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com
N8N_PROXY_HOPS=1
N8N_HOST=staging.revvittsystems.com

تفاصيل خطأ Google تُظهر:

redirect_uri=https://staging.revvittsystems.com/rest/oauth2-credential/callback

هذا يطابق بالضبط ما هو مسجل في Google Cloud Console. جربت أيضاً إنشاء عميل OAuth منفصل تماماً بـ redirect URI للمرحلة الوسيطة فقط — نفس الخطأ.

إنشاء بيانات اعتماد جديدة على الإنتاج (n8n.revvittsystems.com) يعمل فوراً مع نفس تطبيق Google OAuth. المشكلة خاصة بمثيل المرحلة الوسيطة.

يتم إنشاء بيانات الاعتماد من حساب غير إداري/عضو لتجنب خطأ 414 URI Too Long مع حسابات المسؤولين.

5

مرحبا! شكراً على مساعدتك! يرجى الاطلاع على ردي على @Anshul_Namdev. أنا أيضاً أدرجته هنا.

…

مرحبا Anshul!

شكراً على مساعدتك!

طبقت الإصلاحات المقترحة — لا أزال أحصل على redirect_uri_mismatch.

التغييرات التي تمت:

  • أضفت N8N_PROXY_HOPS=1 إلى .env (تم التأكد منها داخل الحاوية عبر docker exec)

  • أضفت X-Forwarded-For و X-Forwarded-Host و X-Forwarded-Proto إلى nginx

  • أعدت تشغيل حاوية nginx و n8n

يؤكد env الحاوية أن جميع المتغيرات صحيحة:

WEBHOOK_URL=https://staging.revvittsystems.com/
N8N_PROTOCOL=https
N8N_EDITOR_BASE_URL=https://staging.revvittsystems.com
N8N_PROXY_HOPS=1
N8N_HOST=staging.revvittsystems.com

تفاصيل خطأ Google تظهر:

redirect_uri=https://staging.revvittsystems.com/rest/oauth2-credential/callback

هذا يطابق بالضبط ما هو مسجل في Google Cloud Console. حاولت أيضاً إنشاء عميل OAuth منفصل تماماً مع redirect URI للتدريج فقط — نفس الخطأ.

إنشاء بيانات اعتماد جديدة على الإنتاج (n8n.revvittsystems.com) يعمل بشكل فوري مع نفس تطبيق Google OAuth. المشكلة خاصة بمثيل التدريج.

يتم إنشاء بيانات الاعتماد من حساب غير إداري/عضو لتجنب خطأ 414 URI Too Long مع الحسابات الإدارية.

6

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

الفحص الحتمي التالي: أنشئ بيانات اعتماد مرحلة اختبار جديدة بعد إعادة تحديث قسرية، ثم قارن معاملات خطأ Google المخفية فقط: لاحقة معرّف العميل، وredirect_uri، والنطاق، والنوع access_type والمحث prompt. لا تنشر السر. إذا كانت لاحقة معرّف العميل ليست عميل المرحلة اختبار الذي تتوقعه، فإن عدم التطابق موجود داخل سجل بيانات اعتماد n8n؛ إذا كانت صحيحة، فإن المشكلة تكون في إعدادات/انتشار عميل Google OAuth بدلاً من nginx.