التحقق من Google OAuth مع عقدة Gmail: كيف تجتاز التحقق عندما يفرض GmailOAuth2Api 6 نطاقات؟

أسئلة
1

مرحباً بالجميع،

أنا أبني مساعد بريد إلكتروني ذكي مُستضاف ذاتياً باستخدام n8n للشركات الصغيرة وأنا حالياً أستعد للتحقق من Google OAuth.

سير العمل:

  • قراءة رسائل Gmail غير المقروءة
  • تصفية رسائل البريد الآلية
  • إرسال المحتوى إلى Claude
  • إنشاء مسودات Gmail
  • وضع علامة على الرسالة كمقروءة فقط بعد المعالجة الناجحة
  • إرسال ملخص التنفيذ

التطبيق لا يحذف رسائل البريد الإلكتروني بشكل دائم.

ما وجدته

بعد التحقيق، اكتشفت أن بيانات اعتماد Gmail OAuth2 API الأصلية لها نطاقات مُرمّزة بقوة.

يطلب دائماً:

  • gmail.labels
  • gmail.addons.current.action.compose
  • gmail.addons.current.message.action
  • mail.google.com
  • gmail.modify
  • gmail.compose

خاصية Scope مخفية، لذا لا توجد طريقة لتخصيصها من واجهة المستخدم.

وجدت أيضاً نقاشات المجتمع تُظهر أن مجرد تقييد النطاقات في Google Cloud يسبب فشل تفويض OAuth مع خطأ HTTP 403 لأن بيانات اعتماد Gmail لا تزال تطلب قائمة النطاق المرمّزة بقوة الكاملة.

هناك أيضاً طلب ميزة مفتوح يطلب من عقدة Gmail دعم بيانات اعتماد Google OAuth العامة بدلاً من بيانات اعتماد Gmail الثابتة.

سؤالي

هل أكمل أحد هنا فعلاً التحقق من Google’s OAuth مع الحفاظ على عقدة Gmail الأصلية؟

إذا كان الجواب نعم:

  • هل قبلت Google النطاقات المرمّزة بقوة الافتراضية؟
  • هل كان عليك تبرير mail.google.com؟
  • هل طلبت Google أي تغييرات؟

أم أنك انتهيت باستبدال عقد Gmail بـ HTTP Request nodes باستخدام بيانات اعتماد Google OAuth2 عامة و Gmail REST API؟

لست أبحث عن نصائح نظرية—أود فعلاً تعليقات من شخص أكمل بنجاح عملية التحقق من Google مع تطبيق n8n في الإنتاج.

شكراً!

شارك سير عملك

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

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

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

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

مرحباً @Jidenkaes
المشكلة ليست في مجموعة النطاقات الستة ككل، بل في أن عقدة Gmail الأصلية تثبّت بشكل مباشر https://mail.google.com/، وهو نطاق مقيّد (وصول كامل، بما في ذلك الحذف الدائم). هذا النطاق الواحد هو الذي يضعك على مسار Google للنطاقات المقيّدة: تقييم الأمان السنوي من جهات خارجية، بالإضافة إلى رفض المراجعين لطلب وصول كامل من تطبيق يقتصر عمله على القراءة والمسودات وتحديد كمقروء.

سير عملك بالكامل (قراءة غير المقروءة، وإنشاء مسودات، وإزالة تصنيف UNREAD) ينطبق ضمن نطاق واحد، gmail.modify. يصنفه Google كحساس وليس مقيّداً، وتحديداً لأنه لا يمكنه حذف البريد بشكل دائم، وهو ما تطبيقك لا يفعله أصلاً. هذا يبقيك في التحقق الأخف للنطاقات الحساسة بدلاً من المقيّدة، ويمنحك تبريراً واضحاً للحد الأدنى من الصلاحيات.

عقدة Gmail لن تسمح لك بتقليل نطاقاتها، لذا استبدل تلك العقد بعقد HTTP Request تضرب Gmail REST API، موثّق باستخدام بيانات اعتماد Google OAuth2 عامة حيث تدخل النطاق بنفسك:

https://www.googleapis.com/auth/gmail.modify
3

شكراً، هذا مفيد جداً. فقط لتوضيح الأمر: هل أكملت شخصياً التحقق من OAuth من Google باستخدام طريقة HTTP Request + generic Google OAuth2، أم أن هذه هي الهندسة التي توصي بها؟ أحاول تحديد ما إذا كان شخص ما قد نجح في اجتياز مراجعة Google بهذا الإعداد.