مرحباً بك في مجتمع n8n ![]()
أتلقى رسالة خطأ عند محاولة توصيل بيانات اعتماد Google Sheets الخاصة بي باستخدام OAuth2. بعد إعداد معرّف العميل والسر، عند النقر على “تسجيل الدخول عبر Google”، أتلقى رسالة الخطأ التالية من Google:
تم حظر الوصول: طلب هذا التطبيق غير صحيح
الخطأ 400: redirect_uri_mismatch
بيئة العمل:
إصدار n8n: Self-hosted (Hostinger VPS)
عنوان URL للمثيل: https://n8n.srv1724629.hstgr.cloud
العقدة: Google Sheets → Create Spreadsheet
نوع بيانات الاعتماد: Google Sheets OAuth2 API
خطوات إعادة الإنتاج:
افتح عقدة Google Sheets في n8n
أنشئ بيانات اعتماد جديدة → Google Sheets OAuth2 API
أدخل معرّف العميل والسر من Google Cloud Console
انقر على “تسجيل الدخول عبر Google”
يعرض Google الخطأ 400: redirect_uri_mismatch
رسالة الخطأ:
تم حظر الوصول: طلب هذا التطبيق غير صحيح
الخطأ 400: redirect_uri_mismatch
لا يمكنك تسجيل الدخول لأن هذا التطبيق أرسل طلباً غير صحيح.
بعد إضافة رابط إعادة التوجيه، تظهر رسالة الخطأ: خطأ في التطبيق
مرحبا @Rohit_Kulkarni
هذا يعني بوضوح أن عنوان URL الذي أعدته للإعادة الموجهة لا يتطابق مع الذي قمت بتكوينه على Google. أولاً، أنصحك بمشاهدة هذا للحصول على فهم أفضل لكيفية إعداد بيانات اعتماد Google:
ثم أخبرني إذا استمرت المشكلة، لأنه في هذه الحالة ستكون مرتبطة بالبنية الأساسية.
يرجى الرد أحد ما
حسناً، إذاً في الوقت الراهن أود منك التحقق من أن WEBHOOK_URL يطابق نطاقك بالضبط. يمكنك تكوينه ثم إعادة تشغيل المثيل الخاص بك ومحاولة إنشاء URI آخر على Google Cloud، وباستخدام معرّف عميل وسري جديد، حاول إنشاء إعادة توجيه فيه. يرجى إخبارني بكيفية سير هذه الخطوات.
أنا لا أفهم ما تحاول قوله، هل يمكنك تبسيطه
مرحباً @Rohit_Kulkarni
أولاً، نافذة الخطأ “الإجراء المحاول فشل” التي تراها في لقطة الشاشة الخاصة بك هي على الأرجح مجرد خلل في موقع Google Cloud. لإصلاح هذا، حاول استخدام نافذة متصفح في وضع التصفح المتخفي أو امسح ذاكرة التخزين المؤقتة. تأكد أيضاً من أنك ملأت بشكل كامل قسم “OAuth Consent Screen” في الشريط الجانبي، حيث لن يسمح لك Google بحفظ الإعدادات إذا كانت معلومات التطبيق الأساسية مفقودة.
ثانياً، يحدث خطأ “redirect_uri_mismatch” لأن Google و n8n لا يتفقان على عنوان الويب الدقيق المستخدم في عملية تسجيل الدخول. فكر في الأمر كمصافحة أمان؛ إذا كان العنوان الذي يرسله n8n إلى Google مختلفاً حتى ولو بقليل عن العنوان الذي حفظته في Google Console، فسيقوم Google بحجب الاتصال لأسباب أمنية.
لحل هذه المشكلة على خادم Hostinger VPS الخاص بك، تحتاج إلى التأكد من أن n8n يعرف عنوانه العام الخاص به. تفعل هذا عن طريق تعيين متغير بيئة يسمى WEBHOOK_URL إلى عنوان HTTPS الكامل الخاص بك. بدون هذا، قد يرسل n8n عنواناً داخلياً أو غير صحيح إلى Google، مما يؤدي إلى خطأ عدم التطابق.
أخيراً، بمجرد تحديث إعداد الخادم، عُد إلى شاشة بيانات اعتماد n8n الخاصة بك وانسخ “OAuth Redirect URL” تماماً كما يظهر. الصق هذا الرابط المحدد في حقل “Authorized redirect URIs” في Google Cloud Console. تأكد أيضاً من إضافة بريدك الإلكتروني كمستخدم اختبار “Test User” في شاشة Google Consent حتى يكون لديك الإذن بتسجيل الدخول.
مرحبا @Rohit_Kulkarni
يرجى التحقق من أنك تقوم بتحرير عميل OAuth في مشروع لديك صلاحيات محرر أو مالك فيه، حاول إنشاء عميل OAuth جديد بدلاً من تحرير الحالي، انتظر بضع دقائق وحاول مرة أخرى (Google Cloud قد تواجه أحياناً عطل مؤقت في الواجهة)، اختبر باستخدام حساب Google آخر لديه وصول إداري للمشروع. من وجهة نظري، يحدث الخطأ في وقت حفظ عميل OAuth.
redirect_uri_mismatch هي طريقة جوجل لإخبارك بأن رابط الاستدعاء الذي أرسله n8n لا يطابق بالضبط ما هو مسجل في عميل OAuth الخاص بك في Google Cloud، والرد أعلاه محق في أن هذا هو ما يجب أن تحرص على توافقه. جزء المطابقة الدقيقة أصرم مما يتوقعه الناس.
بشكل ملموس: افتح بيانات اعتماد Google Sheets الخاصة بك في n8n وانسخ عنوان URL لإعادة توجيه OAuth الذي يعرضه (سيكون https://your-domain/rest/oauth2-credential/callback). الصق هذا النص بالضبط في وحدة تحكم Google Cloud تحت Authorized redirect URIs، حرف بحرف، https وليس http، بدون اختلاف شرطة زائدة في النهاية، نطاقك الحقيقي وليس عنوان IP. على الخوادم المستضافة ذاتياً (Hostinger)، السبب الجذري المعتاد هو عدم تعيين N8N_EDITOR_BASE_URL إلى نطاقك الكامل https، لأن n8n يبني رابط الاستدعاء من هذا المتغير، لذلك إذا كان متغير البيئة خاطئاً أو مفقوداً، فإن عنوان URL الذي يرسله n8n سيكون خاطئاً بغض النظر عما تلصقه في Google.
لذا تحقق من N8N_EDITOR_BASE_URL أولاً، ثم اجعل إدخال وحدة تحكم Google يطابق رابط الاستدعاء الذي يعرضه n8n بالضبط. إذا كان كلاهما متطابقاً وفشل الأمر، فتأكد من أن وكيل العكس الخاص بك يمرر X-Forwarded-Proto https حتى لا يعتقد n8n أنه على http. ما الذي يعرضه عنوان URL لإعادة التوجيه في بيانات اعتمادك على n8n بالفعل، http أم https؟
كنت أواجه نفس المشكلة، تأكد من أنك لا تنشر التطبيق، وأيضاً تأكد من إضافة رسائل بريدك الإلكتروني في قسم المستخدمين الجربين، قد يساعدك ذلك.
