هناك عدة طرق يمكن للمستخدم من خلالها تسجيل الدخول، ومن الصعب إضافة شروط عبر إضافة (plugin) يجب على المستخدم استيفاؤها قبل تسجيل الدخول.
من أمثلة الشروط التي قد يرغب كاتب الإضافة في إضافتها للمصادقة:
- التأكد من أن نطاق بريد المستخدم الإلكتروني يتبع نمطًا معينًا، مثل university.edu
- اجتياز العامل الثاني من مزود المصادقة الثنائية (يبدو أن هناك عددًا لا بأس به من هؤلاء المزودين)
- التأكد من أن المستخدم لديه اشتراك نشط عبر مزود دفع
تُفحص الشروط الحالية (أو لا تُفحص) بشكل مختلف حسب السياق (قائمة غير شاملة):
-
- عبر طريقة
create: كلمة المرور صحيحة، المستخدم معتمد، المستخدم نشط، تم تأكيد بريد المستخدم الإلكتروني، العامل الثاني TOTP، المستخدم معلق، عنوان IP صحيح/خاطئ - عبر طريقة
email_login: العامل الثاني TOTP، المستخدم معتمد، المستخدم معلق، عنوان IP صحيح/خاطئ
- عبر طريقة
-
- عبر
logon_after_password_reset: المستخدم معتمد (لاحظ أن هذا يُفحص مع مثيل جديد منGuardian)، المستخدم من الطاقم
- عبر
-
- عبر
perform_accept_invitation: المستخدم نشط
- عبر
طريقة لإدراج شرط مخصص هي إضافة وحدة مخصصة (custom module) في مقدمة كل طريقة لتعديلها، وهو ما لا يُعد نتيجة مرغوبة من منظور الحفاظ على التوافق مع Discourse، كما أنه غير أنيق.
اقتراح
سيكون من الأسهل التطوير حول المصادقة لو كانت أقل تشتتًا في قاعدة الكود. يمكن تعريف جميع الشروط (رسائل الخطأ استجابةً لها) التي قد يرغب المرء في فحصها كطرق منفصلة في مكان واحد. يجب على المستخدم الذي يرغب في تسجيل الدخول اجتياز كل شرط مفعّل. يمكن لكاتب الإضافة إضافة طرق خاصة به إلى هذا الصنف، والتي ستقوم طريقة log_on_user بفحصها بعد ذلك. إذا أردت تجاوز شرط ما في سياق معين، فيمكنك تمرير معامل (parameter) للقيام بذلك.