مرحباً، لقد فتحت للتو حساب مسؤول على Google Workspace. أنا على وشك القيام بـ Domain Wide Delegation وأعتقد أنني يجب أن أحصل على Client ID والمفتاح من حساب المسؤول.
أريد التأكد من أنني أقوم بهذا بشكل صحيح:
لقد أنشأت Service Account داخل Google Cloud Console ضمن حساب المسؤول الخاص بي (marc95@timealign-ai.com) وقمت بإنشاء ملف مفتاح JSON.
أخذت معرّف عميل OAuth 2.0 الذي يتكون من 21 رقماً من هذا Service Account وألصقته في Google Workspace Admin Console (admin.google.com) ضمن Domain-Wide Delegation مع النطاق [https://www.googleapis.com/auth/calendar](https://www.googleapis.com/auth/calendar).
في n8n، أنا أستخدم بيانات اعتماد Service Account مع تعيين marc95@timealign-ai.com كمستخدم محاكي (رسالة بريد المشروع).
مرحباً @Marc2
هذه الخطوات الثلاث تطابق سير العمل الموثق. يقوم n8n بالتحقق من بيانات اعتماد حساب الخدمة مقابل مجموعة نطاق أوسع من العملية التي تريدها فعلاً، لذا فإن إدخال التفويض الذي يحتوي على نطاق التقويم فقط يعود بـ 401 unauthorized_client عند الحفظ حتى عندما يكون الجانب من Google صحيحاً، تم تتبعه كمشكلة gh 20581. ضع المجموعة الكاملة في نفس إدخال Domain-Wide Delegation:
إصدار Starter ليس مشكلة. التفويض على مستوى المجال غير مقيد بإصدار Workspace. لا تسرد وثائق Google أي قيود على الإصدار، بل فقط امتيازات المسؤول الفائق، وأنت تمتلكها.
خطواتك الثلاث صحيحة. الشيء الوحيد المفقود هو تفعيل Google Calendar API في مشروع Cloud نفسه. على الرغم من أن التفويض يسمح لحساب الخدمة بالتصرف كمستخدم، يجب تفعيل API أيضاً. يكون معطلاً افتراضياً في مشروع جديد. إذا تخطيت هذه الخطوة، ستتلقى رسالة خطأ 403 تفيد بأن API لم يتم استخدامه في المشروع. قد تكون هذه الرسالة مضللة لأنها تشير إلى مشكلة مصادقة، لكن الحالة ليست كذلك.
من المفيد أيضاً معرفة أن التفويض ليس فورياً. وفقاً لوثائق n8n، يستغرق الأمر ما بين خمس دقائق و24 ساعة حتى يعمل المحاكاة. لذلك، لا تفترض أنها مكونة بشكل خاطئ إذا فشلت مباشرة بعد الحفظ.
محاكاة نفسك كمسؤول أمر جيد، يجب فقط أن يكون الموضوع مستخدماً حقيقياً في المجال.