مرحبا @Benjamin2
الخطأ الذي تراه (“فشل الإجراء المحاول، يرجى المحاولة مرة أخرى”) يأتي فعلاً من Google Cloud Console الخاص بـ Google نفسها، وليس من n8n. إنها رسالة عامة تشير إلى أن نظام Google واجه عطلاً أثناء محاولة حفظ إعدادات عميل OAuth الخاصة بك. يحدث هذا عادةً بسبب تضارب في متصفحك بدلاً من أن يكون خطأً في إعدادات n8n الخاصة بك.
السبب الأكثر شيوعاً هو تسجيل الدخول إلى عدة حسابات Google في نفس جلسة المتصفح، مما غالباً ما يربك Google Cloud Console. لإصلاح هذا، الحل الأسرع هو فتح نافذة Incognito أو Private وتسجيل الدخول فقط إلى حساب Google المحدد الذي تستخدمه لهذا الإعداد. إذا لم يفلح ذلك، حاول تعطيل امتدادات المتصفح (مثل المانعات الإعلانية) أو مسح ذاكرة التخزين المؤقت والملفات التعريفية للارتباط في متصفحك.
وأخيراً، تحقق مرة أخرى من أنك اخترت “تطبيق الويب” كنوع التطبيق. عند لصق Redirect URI من n8n، تأكد من عدم وجود مسافات عرضية في بداية أو نهاية الرابط. نظراً لأنك تستضيف ذاتياً عبر Hostinger، تحقق أيضاً من أن متغير البيئة WEBHOOK_URL في بيئة n8n الخاصة بك معين بشكل صحيح ويتضمن بادئة https://، حيث أن بروتوكول مفقود قد يتسبب في رفض Google للطلب.
شكراً جزيلاً @kjooleng على النصائح. جربت كل ما قلته
لكنني لا أزال أتلقى نفس إشعار الخطأ.
نظرًا لأن تغييرات المتصفح لم تحل المشكلة، سأتوقف عن التعامل مع هذا كمشكلة في n8n في الوقت الحالي واختبر مشروع Google نفسه. إذا لم يتمكن نفس حساب Google أو المشروع من إنشاء أي عميل OAuth، فمن المحتمل أن تكون المشكلة من جانب Google بدلاً من أن تكون في n8n. هل يمكنك تأكيد ما إذا كان هذا مشروعًا جديدًا تمامًا أم مشروعًا معاد استخدامه من إعداد قديم؟
@OMGItsDerek شكراً جزيلاً على ردك.. هذا مشروع جديد تماماً. أنا في الواقع أحاول إعداد هذا لزميلة تعمل في نفس المنظمة التي أعمل فيها. تحققت مرتين:: لا توجد لديّ مشاكل عندما أضيف عميلاً آخر في لوحة تحكم Google الخاصة بي. معها أحصل دائماً على نفس إشعار الخطأ. هل لديك أي نصائح لحل هذه المشكلة؟
مرحبا @Benjamin2
بناءً على معلوماتك الجديدة، إليك ما قد يكون حدث
الخطأ الذي تراه هو رسالة عامة “تجميع الكل”، مما يعني أن Google تعرف أن شيئاً ما خاطئ لكنها لا تخبرك بالضبط ما هو. بما أنك تستطيع إنشاء عملاء لنفسك لكن لا تستطيع لحساب زميلتك الجديد، فالمشكلة ليست في العملية نفسها، بل على الأرجح إعداد مفقود أو قيد مرتبط بذلك الحساب الجديد المحدد.
السبب الأكثر شيوعاً هو “OAuth Consent Screen”. فكر في هذا باعتباره “حصيرة الترحيب” الرقمية التي يراها المستخدمون عند تسجيل الدخول. كل مشروع جديد يتطلب شاشة موافقة خاصة به يتم إعدادها بالكامل. إذا كان أي حقل مطلوب فارغاً أو لم يتم “حفظه والمتابعة” حتى النهاية، فسيمنعك Google من إنشاء معرّف العميل.
يجب عليك أيضاً التحقق من أذونات الحساب. حتى لو كانت زميلتك جزءاً من مؤسستك، قد لا تمتلك دور “محرّر” أو “مالك” لهذا المشروع المحدد. إذا كانت تمتلك “عارض” أو وصول محدود، فقد تسمح لها وحدة التحكم بفتح صفحة الإنشاء، لكنها ستُطلق خطأ في اللحظة التي تحاول فيها حفظ المعرّف الجديد بالفعل.
لأن هذا حساب Gmail جديد تماماً، قد يطبق Google “فترة راحة” أمان مؤقتة. لمنع البريد العشوائي، تقيد Google أحياناً الحسابات الجديدة من إنشاء بيانات اعتماد أمان لعدة أيام. بالإضافة إلى ذلك، تأكد من أن التطبيق مضبوط على “داخلي” (لشركتك فقط) وليس “خارجي”، لأن التطبيقات الخارجية تتطلب عملية تحقق أكثر صرامة بكثير.
لا تتجاهل الأعطال البسيطة في المتصفح. وحدة تحكم Google Cloud معقدة جداً وغالباً ما تشعر بالارتباك من ملفات تعريف الارتباط القديمة أو البيانات المخزنة مؤقتاً من حسابات أخرى. غالباً ما يؤدي التبديل البسيط إلى نافذة “Incognito” أو “Private”، أو محاولة متصفح مختلف تماماً، إلى حل هذه الأخطاء “الشبحية” التي ليس لها سبب تقني واضح.
لحل هذه المشكلة بسرعة، ابدأ بتجربة نافذة Incognito. إذا لم ينجح ذلك، عد إلى “OAuth Consent Screen” وتأكد من أن كل صفحة مملوءة ومحفوظة. أخيراً، تحقق من أن زميلتك مدرجة باسم “محرّر” في إعدادات IAM للمشروع. إذا فشلت جميع تلك المحاولات، فانتظر 24 إلى 48 ساعة ليتم الوثوق بالحساب الجديد بالكامل من قبل النظام.
يحدث هذا عادةً عندما تكون عنوان URL للـ webhook أو عنوان URL العام لـ n8n خاطئاً أو لم يتم تعيينه بشكل صحيح، مما يؤدي إلى إنشاء عنوان URL إعادة التوجيه OAuth بشكل غير صحيح.
يحدث هذا في الحسابات الجديدة عندما لا يتم إعداد شاشة موافقة OAuth أولاً. قبل إنشاء معرّف العميل:
انتقل إلى APIs & Services > OAuth consent screen وأكمل هذا الإعداد
ثم انتقل إلى APIs & Services > Library وفعّل واجهة برمجية التطبيقات المحددة التي تحتاجها (Gmail API أو Google Drive أو غيرها)
ثم أنشئ بيانات الاعتماد
إذا كنت قد أكملت بالفعل هذه الخطوات، حاول في نافذة متخفية؛ وحدة التحكم في Google Cloud تخزّن أحياناً حالة سيئة تمنع إنشاء بيانات الاعتماد.
انتقل إلى إعدادات شاشة موافقة OAuth في وحدة تحكم Google Cloud. انظر إلى نوع المستخدم. إذا كان مضبوطًا على Internal، فسيرفض فورًا أي شخص لا يملك اسم نطاق بريد إلكتروني مطابقًا تمامًا لك. غيّر نوع المستخدم إلى External، احفظه، ثم حاول إضافتهم.
أخبرني إذا نجح هذا، أو إذا كان لديكما نفس البريد الإلكتروني.
أواجه نفس المشكلة، أنا أستخدم عنوان URL الخاص بي للاسترجاعية صحيح لكنني لا أعرف كيفية التعامل مع هذه المشكلة المزعجة. لقد قمت بربط 3 عمليات مصادقة Gmail بحساب واحد، هل يمكن أن يكون هذا هو السبب في حجب Google لي؟ هل يجب أن أستضيف نسخة n8n جديدة أم ماذا؟
شكرًا جزيلاً @SE-automations لكنني كنت قد وضعته بالفعل على خارجي. أحصل على نفس الخطأ
@Oguzhan_Murat هذا سيكون أيضاً حسابي الثالث للاتصال. لم تكن لدي مشاكل من قبل لكن مع هذا الحساب أواجه مشكلة. لست متأكداً إن كانت هذه هي المشكلة الحقيقية
شكراً لك كثيراً @Asim_Arman. لقد فعّلت جميع واجهات برمجة التطبيقات التي احتجتها مسبقاً. للأسف، لم يُحدث ذلك أي فرق. وضع المتصفح الخاص لم يساعد أيضاً. غريب جداً!
يا جماعة، أنا جديد تماماً على هذا الموضوع لكن واجهت نفس المشاكل بالضبط أثناء الإعداد وكان هناك خطأ. إليك الحل الذي اكتشفته بمساعدة الذكاء الاصطناعي، آمل أن يساعدكم 
Google لم تعد تسمح باستخدام نطاق Hostinger الافتراضي في قسم العلامات التجارية كنطاق من الدرجة الأولى. يجب بالضرورة إدخال نطاق خاص بك هناك.
الحل بسيط جداً: تستخدم نطاقاً خاصاً بك، وتنشئ نطاقاً فرعياً عن طريق إدخال CNAME (على سبيل المثال بـ api. في الأمام) وتدخله في لوحة التحكم في Hostinger عبر محرر .yaml. بهذه الطريقة، يختفي نطاق Hostinger وكل شيء يعمل بشكل مثالي.
للحصول على إرشادات حول بقية ربط Google، يساعدك هذا الفيديو:
إليك ملخص سريع للخطوات:
1. إنشاء إدخال CNAME لدى مزود النطاق
الموقع الرئيسي لا يتم تغييره. يتم فقط إنشاء نطاق فرعي لدى مزود النطاق الخاص بك:
النوع: CNAME
اسم المضيف/الاسم: api (أو أي اختصار آخر)
الهدف/القيمة: عنوان Hostinger الكامل مع نقطة في النهاية (على سبيل المثال n8n.srvXXXXX.hstgr.cloud.).
مهم: اترك الخيار “نطاق فرعي؟” معطلاً ولا تنس النقطة في نهاية رابط الويب!
2. التعديل في لوحة Hostinger
حتى يستخدم n8n العنوان الجديد، يتم تعديل مشروع Docker في Hostinger:
في قائمة VPS انتقل إلى مدير Docker → المشاريع وقم بـ إدارة مشروع n8n.
في الأسفل في قسم البيئة (Environment) غير المتغيرات:
DOMAIN_NAME = eigene-domain.de (النطاق الرئيسي الخاص بك بدون www أو https)
SUBDOMAIN = api (اختصار CNAME الذي اخترته)
انقر على حفظ ونشر. يقوم Hostinger بإعادة تشغيل n8n وإنشاء شهادة SSL.
3. إنهاء Google Cloud Console
شاشة موافقة OAuth: في النطاقات المصرح بها أدخل الآن نطاقك الرئيسي (على سبيل المثال eigene-domain.de). يقبل Google هذا النطاق من الدرجة الأولى الآن على الفور.
بيانات الاعتماد: في OAuth Client ID تحت معرفات إعادة التوجيه المصرح بها أدخل رابط استدعاء n8n الجديد مع النطاق الجديد: https://eigene-domain.de
أعتذر عن عدم نجاحه، ربما ستنجح هذه الطريقة:
في Google Cloud، انتقل إلى تبويب شاشة موافقة OAuth. ضمن نوع المستخدم، إذا كنت تستخدم حساب @gmail.com عادياً، يجب أن تتركه كـ External لكن ابحث عن قسم Publishing status. تأكد من ضبطه على Testing mode (لا تنقر على Publish App). أخيراً، يجب أن تضيف عنوان بريدك الإلكتروني الجديد بشكل صريح إلى قائمة Test users أسفله مباشرة. إذا لم يكن بريدك الإلكتروني في قائمة الاختبار، فستحظره Google من الاتصال.
أخبرني إذا نجح هذا.
أهلا وسهلا بك في مجتمع n8n @Benjamin2
بما أن هذا يعمل في حسابك لكنه يفشل في حساب زميلتك، سأتحقق من أذونات/قيود Google Workspace أو سأنشئ OAuth Client في المشروع باستخدام حساب بدور Owner/Editor. ما عليك سوى نسخ عنوان URL إعادة التوجيه من بيانات اعتماد Google والصقه في Authorized redirect URIs.
إذا استمرت الأخطاء، يرجى مشاركة ملف json الخاص بك بدون البيانات الحساسة لفهم الحالة بشكل أفضل.
أواجه نفس المشكلة. بيانات اعتماد Google Calendar كانت تعمل حتى قبل حوالي أسبوع، لكنها توقفت فجأة عن العمل.
تطبيق Google Cloud Console الخاص بي لا يقبل عناوين URL من Hostinger بعد الآن.
مرحبا بالجميع،
شكراً جزيلاً على ردودكم. في النهاية، تمكنت من حل المشكلة.
للأسف، لا يمكنني التأكد بشكل قاطع ما الذي حل المشكلة بالضبط. أفضل تخمين لدي هو أن هناك شيئاً خاطئاً في إعدادات مشروع Google Cloud الذي أنشأته.
لم أغير أي شيء في Hostinger أو إعدادات النطاق أو أي شيء مشابه لجعله يعمل. حاولت ببساطة مرة أخرى واستخدمت المشروع الافتراضي الأولي، “My First Project”، دون إعادة تسميته.
فجأة، بدأ كل شيء يعمل.
شكراً مرة أخرى على مساعدتكم!
@albertocv بخصوص مشكلة رابط Hostinger - بدأت Google في فرض التحقق الأكثر صرامة من المجالات لأصول OAuth المصرحة. الحل الشائع: تأكد من أن إدخال “Authorized JavaScript origins” يطابق تماماً مجال Hostinger الخاص بك بما في ذلك البروتوكول (على سبيل المثال https://yourapp.hostinger.com بدون شرطة مائلة نهائية)، وأضف رابط callback الخاص بمثيل n8n الخاص بك إلى “Authorized redirect URIs” بالصيغة https://yourapp.hostinger.com/rest/oauth2-credential/callback. إذا كنت تستخدم نطاق فرعي على Hostinger، جرّب أيضاً إضافة المجال الجذري كمجال مصرح به في شاشة موافقة OAuth.
سأتحقق من هذا كمشكلة في إعدادات Google Cloud OAuth أولاً، وليس كمشكلة في سير عمل n8n.
قائمة التحقق المعتادة هي:
1. في Google Cloud Console، تأكد من أن نوع عميل OAuth هو Web application، وليس Desktop.
2. أضف رابط إعادة التوجيه الدقيق لـ n8n المعروض في شاشة بيانات اعتماد Google في n8n إلى Authorized redirect URIs. يجب أن يطابق تماماً، بما في ذلك http/https وأي مسار.
3. إذا كانت شاشة موافقة OAuth لا تزال في Testing، أضف حساب Gmail الذي تستخدمه ضمن Test users.
4. فعّل واجهات برمجية التطبيقات المطلوبة للبيانات الاعتمادية، على سبيل المثال Gmail API أو Google Sheets API حسب العقدة.
5. بعد تغيير رابط إعادة التوجيه أو إعدادات الموافقة، أنشئ اتصال بيانات اعتماد جديد في n8n بدلاً من إعادة استخدام نافذة منبثقة فاشلة قديمة.
للـ n8n ذاتي الاستضافة، تحقق أيضاً من أن عنوان n8n العام الخاص بك مستقر وأن WEBHOOK_URL / N8N_EDITOR_BASE_URL يشيران إلى نفس المجال العام الذي تستخدمه في المتصفح. عدم التطابق هناك غالباً ما ينشئ عنوان رد نداء خاطئ.
يمكن تشخيص هذا بشكل غير متزامن من خلال لقطة شاشة معاد صياغتها لرابط رد الاتصال لبيانات اعتماد n8n وقائمة إعادة التوجيه OAuth في Google Cloud. لا يلزم الوصول إلى الحساب.
