دعوة زميل إلى بوابة العملاء: متى يبدأ حق الوصول فعلياً؟
ينبغي أن تعرض الدعوة عضوية محددة، لا أن تمنح صلاحية الدخول بمجرد أن يكتب المسؤول عنوان بريد. قبل طلب تطوير بوابة للفريق، حدد مساحة العمل المقصودة، ومن يحق له قبول الدعوة، والصلاحيات التي يحصل عليها بعد القبول، وطريقة سحب الدعوة ما دامت معلقة. يجب أن تميز الواجهة بوضوح بين «تمت دعوته» و«أصبح عضواً».
هذا المقال عن الانضمام إلى فريق أو مساحة خاصة بعميل. أما تحديد صلاحيات الأدوار فله دليل مستقل لتخطيط الوصول. السؤال هنا يسبق ذلك: كيف تصبح للشخص الصحيح عضوية تخوله استخدام الدور المعروض؟
الحساب ليس هو العضوية
قد يستخدم الشخص خدمتك بالفعل لصالح شركة أخرى. لا ينبغي افتراض أنه يحتاج إلى هوية ثانية غير مرتبطة بالأولى، ولا أن تسجيل دخوله يجعله عضواً في كل شركة تحمل اسماً مشابهاً.
اطلب من المطور توضيح الفصل بين حساب المستخدم وعضوياته. في مثال افتراضي، تعمل محاسبة مع عميلين داخل البوابة نفسها. تستطيع قراءة المستندات لدى الأول وتعديلها لدى الثاني. قبول دعوة جديدة لا ينبغي أن ينسخ صلاحيات عضوية أخرى تلقائياً.
تقدم وثائق دعوات المؤسسات في Auth0 مثالاً محدداً: يمكن دعوة شخص لا يملك حساباً بعد، أو مستخدم موجود لكنه ليس عضواً في المؤسسة. وتوضح أن دور المؤسسة المحدد مسبقاً يسري عند تسجيل الدخول من خلال تلك المؤسسة. هذه خصائص موثقة لدى Auth0، وليست وعداً بشأن كل بوابة أو خطة اشتراك.
وضح العرض قبل أن يقبله المستلم
ينبغي أن تسمي رسالة الدعوة وشاشة القبول الشركة أو مساحة العمل، وتشرحا سبب الدعوة، وتصفا الدور بلغة مفهومة. كلمة «عضو» لا تكفي إذا كانت تعني السماح بتنزيل جميع سجلات العملاء.
اتفق أيضاً على وجهة المستخدم بعد القبول. من دُعي إلى مساحة معينة ينبغي أن يصل إليها، لا أن يجد نفسه أمام شاشة إعداد عامة بلا تفسير. وإذا كان مسجلاً بعنوان مختلف، فأظهر سبب التعارض وطريقة واضحة لتبديل الحساب. لا تربط الدعوة سراً بالحساب المفتوح حالياً.
تشترط Auth0 في هذه الدعوات تسجيل الدخول أو إنشاء حساب بالعنوان الذي أُرسلت إليه الدعوة. وعند استخدام تسجيل دخول اتحادي، يجب أن يعيد مزود الهوية عنوان البريد المطابق. اطلب عرض القاعدة المقابلة في النظام المختار، بدلاً من افتراض أن امتلاك رابط أُعيد توجيهه يكفي لإثبات أهلية الانضمام.
حدد ما يحدث بين الإرسال والانضمام
يمكن اعتماد حالات واضحة مثل «معلقة» و«مقبولة» و«منتهية» و«مسحوبة». هذه توصية لتصميم سير العمل، وليست ادعاء بأن جميع المزودين يستخدمون هذه التسميات.
ما دامت الدعوة معلقة، ينبغي أن يرى المسؤول المستلم ومساحة العمل والدور المعروض وموعد انتهاء الصلاحية. قرر هل يمكن تغيير الدور بعد الإرسال. من السياسات المفهومة سحب الدعوة القديمة وإصدار أخرى عندما تتغير الصلاحيات، حتى لا يقبل المستلم وصفاً لم يعد صحيحاً.
اختر مدة صلاحية تناسب العمل، وحدد معنى «إعادة الإرسال». هل تستبدل الدعوة السابقة أم يظل الرابطان صالحين؟ ماذا يظهر لمن يفتح الرسالة الأقدم؟ لا تعرض عبارة «أُلغي الرابط السابق» إن كان الخادم ما زال يقبله.
تذكر وثائق Auth0 أن الدعوة التي لا تُقبل قبل انتهاء صلاحيتها تُعلّم كمنتهية ثم تُحذف لاحقاً من لوحة التحكم. لا يحدد هذا مدة الاحتفاظ المناسبة لسجلات مشروعك، ولا يثبت أن لوحة المزود تكفي لتوثيق قرارات المؤسسة. حدد احتياجات المتابعة والدعم والاحتفاظ بصورة مستقلة.
سحب الدعوة يختلف عن إزالة عضو
اختبر ما قبل القبول وما بعده. سحب دعوة معلقة ينبغي أن يمنعها من إنشاء عضوية جديدة. أما بعد انضمام الشخص، فيصبح سحب وصوله إجراءً لإدارة العضوية، وليس إلغاءً متأخراً للدعوة.
وفرق بين إزالة العضوية من مساحة واحدة وإغلاق حساب الشخص بالكامل. قد يظل محتاجاً إلى مساحات عمل أخرى. اسأل عما يحدث للجلسات النشطة والصفحات المفتوحة بعد سحب الوصول. هذه مسألة تنفيذ ومراجعة أمنية، ولا يحسمها تغيير اسم الزر.
استخدم عناوين وهمية ومساحة تجريبية عند العرض والاختبار. لا تضع روابط الدعوة الحقيقية في لقطات الدعم المعتادة أو ملاحظات المشروع المشتركة. حدد البيانات التي يحتاج موظف الدعم إلى رؤيتها، من دون أن تمنحه القدرة على الانضمام بنفسه إلى مساحة العميل.
ما الذي ينبغي عرضه قبل التسليم؟
اطلب تنفيذ الرحلة في نسخة اختبار معزولة، مع التحقق من الآتي:
- يقبل شخص جديد الدعوة ويحصل على الوصول المعروض فقط.
- ينضم مستخدم موجود إلى مساحة ثانية من دون تغيير عضويته الأولى.
- لا تُقبل الدعوة خفية باستخدام عنوان مختلف مسجل حالياً.
- لا تنشئ الدعوة المنتهية أو المسحوبة عضوية.
- تتطابق نتيجة إعادة الإرسال مع وصف الرسالة وواجهة المسؤول.
- لا ينشئ فتح الرابط مجدداً بعد القبول عضوية إضافية أو صلاحيات أوسع.
- تؤثر إزالة عضو في المساحة المطلوبة، ولا تحذف حساباً آخر غير مقصود.
سجل النتيجة المتوقعة لكل حالة في متطلبات المشروع. هذه العروض تختبر السلوك المتفق عليه، ولا تمثل تقييماً أمنياً شاملاً. إذا كانت الدعوات جزءاً من بوابة تنوي تطويرها، فناقش دورتها ضمن متطلبات تطوير المواقع وتطبيقات الويب.
المصدر وحدود الاستناد إليه
Auth0، Invite Organization Members: https://auth0.com/docs/manage-users/organizations/configure-organizations/invite-members
يدعم المصدر وصف سلوك Auth0 المتعلق بالحساب والمؤسسة ومطابقة البريد وانتهاء الدعوة. يعتمد توفر الميزة على التنفيذ والخطة. أما تسميات الحالات وتوصيات الواجهة وحالات التسليم فهي إرشادات عملية لطلب التطوير، وليست متطلبات قانونية أو ضمانات عامة بشأن المزودين.