أنا أقوم بإعداد سير العمل لعدة مستخدمين مختلفين. كيف يمكنني إعداد بيانات الاعتماد لكل منهم دون الحاجة إلى الوصول إلى حساباتهم الشخصية، أم يمكنهم إنشاؤها بأنفسهم؟
مرحبًا @Bobby_Cheung
إذا كنت تستخدم إصدارًا من n8n مفعّلاً فيه إدارة المستخدمين (متاح في n8n Cloud وفي معظم التثبيتات الذاتية)، فإن العملية واضحة جدًا:
- دعوة المستخدمين: تدعو المستخدمين إلى مثيل n8n الخاص بك عبر البريد الإلكتروني.
- بيانات الاعتماد الخاصة: بمجرد تسجيل دخولهم، أي بيانات اعتماد ينشئونها تكون خاصة بهم بشكل افتراضي.
- تنفيذ سير العمل: عندما تنشئ سير عمل لهم، يمكنك ترك حقل بيانات الاعتماد فارغًا أو تعيينه إلى عنصر نائب. عندما يفتح المستخدم سير العمل، يختار ببساطة بيانات اعتماده المُعدّة مسبقًا من القائمة المنسدلة.
بالنسبة للخدمات التي تدعم OAuth2 (مثل Google و Slack و Microsoft وغيرها)، لا يضطر المستخدم أبدًا إلى إعطاؤك كلمة المرور الخاصة به:
- تقوم بإعداد “التطبيق” (معرّف العميل والسر) في وحدة تحكم المطورين بالخدمة.
- ينقر المستخدم على زر “ربط حسابي” في n8n.
- يتم إعادة توجيهه إلى صفحة تسجيل الدخول الخاصة بالخدمة (على سبيل المثال، شاشة تسجيل الدخول لدى Google)، حيث يصرح بـ n8n.
- يستقبل n8n “رمزًا” للعمل نيابة عنه، لكنك لا تشاهد بيانات اعتماد تسجيل الدخول الفعلية أبدًا.
إذا أنشأت “حساب خدمة” (حساب عام تستخدمه الشركة) وتريد لعدة مستخدمين استخدامه دون معرفة كلمة المرور:
- تنشئ بيانات الاعتماد تحت حسابك كمسؤول.
- في إعدادات بيانات الاعتماد، يمكنك مشاركة بيانات الاعتماد المحددة تلك مع مستخدمين آخرين أو أدوار معينة.
- يمكن للمستخدمين بعد ذلك اختيار بيانات الاعتماد المشتركة في سير عملهم، لكن لا يمكنهم رؤية أو تحرير مفتاح API أو كلمة المرور الفعلية.
هذا يعتمد على نوع بيانات الاعتماد التي تقوم بإعدادها.
للخدمات المشتركة (روبوت Slack، أو اتصال قاعدة بيانات، أو واجهة برمجية داخلية، أو أي شيء يقدم حسابًا واحدًا للفريق بأكمله): يمكنك إنشاء بيانات الاعتماد بنفسك، ثم فتحها والنقر على علامة تبويب المشاركة. توجد قائمة منسدلة لمشاركتها مع مستخدمين أو مشاريع محددة. سيتمكنون من استخدامها في سير العمل، لكنهم لن يرون مفتاح API أو السر الفعلي. يبقى مقفولًا لك كمالك.
لحسابات OAuth الشخصية (حساب Gmail الخاص بكل شخص وGoogle Drive وNotion وما إلى ذلك): لا توجد طريقة للالتفاف حول ذلك. يحتاج كل مستخدم للمصادقة باستخدام حسابه الخاص. لا يمكنك القيام به نيابة عنهم دون تسجيل الدخول باسمهم. الخبر السار هو أن العملية تكون نفسها بالنسبة لهم كما هي بالنسبة لك: بيانات الاعتماد → إضافة بيانات اعتماد → اختيار الخدمة → المرور بخطوات OAuth. طالما لديهم حساب n8n على مثيلك، يمكنهم القيام بذلك بأنفسهم.
عمليًا: تقوم بإعداد بيانات اعتماد الخدمات المشتركة ومشاركتها، وينشئ أعضاء فريقك بيانات اعتمادهم الخاصة لأي شيء مرتبط بحساباتهم الشخصية.
شيء صغير يستحق المعرفة: المستخدمون الذين تشارك معهم بيانات الاعتماد يمكنهم استخدام بيانات الاعتماد في سير العمل لكن لا يمكنهم عرض أو تعديل السر الأساسي. إذا انتهت صلاحية رمزهم أو حدث خلل ما، فإما أنك تعيد مشاركة رمز جديد أو يحتاجون إلى إعادة المصادقة بأنفسهم. يستحق الأمر تحديد هذا التوقع مقدمًا.
مرحبا! عثرت على هذا الموضوع لأن مناقشتي الخاصة حول Credential HUB تم ربطها ضمن المواضيع ذات الصلة.
من خلال قراءة حالة الاستخدام الخاصة بك، أعتقد أنك قد تواجه واحدة من المشاكل التي تم بناء Credential HUB لمعالجتها: إدارة بيانات الاعتماد المركزية، والوصول المتحكم به للمسارات العملية، ودورة حياة بيانات الاعتماد والتدوير، ومراقبة الصحة، وواجهة برمجية تطبيقات متسقة لمنصات الأتمتة.
قد تكون أو لا تكون الخيار المناسب لإعدادك، لكن إذا كنت مهتماً، إليك نظرة عامة على المشروع وما يهدف إلى حله:
سأقدّر حقاً أي ملاحظات أو آراء من الأشخاص الذين يتعاملون مع تحديات مماثلة.
لويس
مرحباً @Bobby_Cheung
نعم، يمكنهم إنشاء واحد بخاصتهم — وعادة ما يجب أن يفعلوا ذلك.
النقطة الرئيسية: لا تحتاج أبداً إلى كلمة المرور الخاصة بهم. بالنسبة لخدمات OAuth (Google و Slack و Microsoft)، تقوم بإعداد تكوين التطبيق مرة واحدة و هم ينقرون على Connect ويصرحون بحسابهم الخاص.
1. ادعُهم إلى نسختك. يقومون بإنشاء بيانات الاعتماد ومشاركتها في مشروع. يمكنك استخدامها، لكن لا يمكنك عرض أو تعديل السر. يعمل على جميع خطط Cloud.
مشاركة سير العمل تتجاوز هذا — يحصل المحررون على إمكانية الوصول إلى كل بيانات اعتماد بداخله.
2. بيانات اعتماد المستخدم النهائي (Enterprise، معاينة). قالب بيانات اعتماد واحد، يقوم كل مستخدم بتوصيل حسابه الخاص. تعمل التشغيلات باستخدام من قام بتشغيلها.
OAuth فقط، وتشغيلات يدوية/Chat Hub/MCP فقط — وليس مجدول أو webhook.
3. نسخة منفصلة لكل عميل. يمتلكون الحساب ويدعونك فيه. أنظف حد، سهل الانتقال. العيب: التبديل بين النسخ.
4. حسابات الخدمة (Google فقط). يشارك العميل الجدول أو المجلد المحدد فقط مع بريد حساب الخدمة. لا يوجد حساب شخصي متورط على الإطلاق.