يمكن لمجتمعات Discourse الآن أن تسمح للمستخدمين بتسجيل الدخول باستخدام رمز قصير مُرسَل عبر البريد الإلكتروني بدلاً من رابط سحري، مما يوفر تجربة تسجيل دخول بدون كلمة مرور تشبه تلك الموجودة في العديد من منصات SaaS الأخرى وتعمل بالتزامن مع إعداد المصادقة الثنائية الحالي لديك.
في هذا الموضوع، سنراجع التغييرات الرئيسية ونشارك كيفية البدء في استخدام هذه الميزة اليوم.
بعض التفاصيل الجديرة بالمعرفة: الرموز صالحة لمدة 10 دقائق، وتنتهي صلاحيتها بعد 5 محاولات فاشلة، ولا يمكن استخدامها إلا مرة واحدة.
تفعيل رموز تسجيل الدخول لمرة واحدة في مجتمعك
في الوقت الحالي، يُعتبر هذا التغيير تجريبياً! قبل تعميمه على نطاق أوسع، نرحب بملاحظاتكم لمساعدتنا على إجراء التحسينات.
لتفعيل هذه الميزة، انتقل إلى صفحة التغييرات القادمة في منطقة المسؤول الخاصة بك (/admin/config/upcoming-changes) وابحث عن عنصر تمكين تسجيل الدخول المحلي عبر الرمز. قم بتحديث حقل مُفعّل لـ… لإدراج موقعك في هذا التصميم الجديد:
قبل التفعيل، تأكد من أن كلًا من enable_local_logins و enable_local_logins_via_email مضبوطان على true لأن الميزة لا يمكن تفعيلها بدونهما. إذا كنت تستخدم DiscourseConnect (enable_discourse_connect)، فلا يمكن تفعيل هذه الميزة.
بمجرد تفعيل التغيير، تظهر مسار تسجيل الدخول بالرمز تلقائياً.
ما رأيك؟
دوركم الآن: نود أن نعرف رأيكم في هذه الميزة الجديدة. ما الذي يعجبكم وما الذي لا يعجبكم؛ ما الذي يعمل بشكل جيد، وما الذي يمكن تحسينه؟
هذا المسار الجديد يلغي استراتيجية “إنشاء البريد الإلكتروني، كتابة اسم المستخدم، إنشاء كلمة المرور، والحفظ” التي دفعني مدير كلمات المرور للالتزام بها، ويجبرك على كتابة البريد الإلكتروني أولاً قبل كل شيء. لا أجد مشكلة في فكرة رمز البريد الإلكتروني (وأفضلها في الواقع، خاصة إذا كان الرمز مضمناً في موضوع البريد) لكنني أعارض بشدة إزالة حقول بيانات الحساب الأخرى. لو كنت مستخدماً لا يملك أي خلفية تقنية، لوجدت نفسي أيضاً لا أشارك بريدي الإلكتروني في حقل لا يحتوي على أي معلومات مثل هذا لأنه ليس تصميماً شائعاً. قبل أن يصبح هذا أمراً دائماً، سيكون رائعاً لو تمت إضافته مرة أخرى.
رموز البريد الإلكتروني، والمعروفة أيضًا باسم “الروابط السحرية”، مقبولة، لكن تشجيع المستخدمين على استخدام مفاتيح المرور (Passkeys) يجعل التجربة أفضل بكثير.
إحدى أكبر المشكلات المتعلقة برموز البريد الإلكتروني هي أنها لا تؤدي الوظيفة التي يتوقعها المستخدمون في المتصفحات داخل التطبيقات، بما في ذلك متصفح Gmail داخل التطبيق.
ربما تكون المشكلة الأكثر شيوعًا التي يواجهها الأشخاص مع الروابط السحرية هي أنهم يعتقدون أنهم قد سجلوا الدخول إلى الموقع عبر متصفحاتهم العادية، لكنهم في الواقع يسجلون الدخول عبر متصفح داخل التطبيق. على سبيل المثال، قد يتلقى شخص ما رابط تسجيل الدخول إلى بريده الإلكتروني. ثم يفتح تطبيق Gmail، وينقر على زر “تسجيل الدخول إلى 404 Media”، فيقوم هاتفه بتحميل صفحة الويب. لكن هذا يقوم بتحميل الموقع في متصفح الويب الخاص بـ Gmail، وليس في متصفح Safari الأصلي.
تعالج مفاتيح المرور هذه المشكلة.
للبدء، يمكن للمواقع التي تستخدم الروابط السحرية جعل مفاتيح المرور ميزة اختيارية (Opt-in) للعملاء الذين اشتكوا من طريقة عمل روابطهم السحرية الحالية. لضمان عدم التسبب في أي مشكلات، كنوع من الإطلاق التدريجي، يمكنهم جعل هذه ميزة اختيارية بنسبة 100%.
بعد فترة قصيرة، عندما يقتنع مشغلو الموقع بأن مفاتيح المرور تساعد حقًا في حل مشكلات تجربة المستخدم المتعلقة بالروابط السحرية، يمكنهم تشجيع المستخدمين على إضافة مفاتيح المرور بعد تسجيل الدخول، مرة كل 90 يومًا تقريبًا، أو كلما سجلوا الدخول باستخدام ميزة تسجيل الدخول عبر الأجهزة المتعددة الخاصة بمفاتيح المرور. يمكن أن يكون إطار هذا التوجيه للمستخدمين على أجهزة Apple كالتالي: هل تريد تجنب الاضطرار إلى التحقق من بريدك الإلكتروني في المرة القادمة؟ قم بإعداد مفتاح مرور لاستخدام Face ID أو Touch ID لتسجيل الدخول بسرعة وأمان.
أعجبني هذا النهج كثيراً! ومع ذلك، يزعجني قليلاً عدم إمكانية تغيير اسم العرض قبل اكتمال التسجيل. أعتقد أنه سيكون رائعاً إضافة خيار لتغييره أثناء العملية.
في مجتمعنا، قمت بتعطيل إعداد الموقع إعطاء الأولوية لاسم المستخدم في واجهة المستخدم، مما يعني أن الاسم الكامل/اسم العرض هو الأولوية في جميع أنحاء الواجهة. بسبب ذلك، تبدو الأسماء المخصصة تلقائياً مثل “user21” سيئة للغاية في الواجهة الأمامية إذا لم يكن لدى المستخدم خيار فوري لتخصيصها.
لا يرسل هذا المسار الجديد رابطًا سحريًا. إنه يرسل الكود فقط. يبقى المستخدم على نفس الصفحة، وينسخ/يلصق الكود من بريده الإلكتروني إلى نموذج التسجيل. لذا فإن هذا النهج الجديد يساعد بالفعل في التعامل مع المتصفحات داخل التطبيقات (وهي إحدى المزايا الرئيسية لهذا التغيير).
هذا بالتأكيد شيء نود القيام به لاحقًا، في خطوة كلمة المرور أثناء التسجيل. لقد كثفت التطبيقات والمواقع الإلكترونية دعمها لمفاتيح المرور، وأستمر في رؤية تشجيع استخدام مفاتيح المرور في العديد من السياقات، لذا فمن المنطقي إضافتها إلى Discourse أيضًا. (إن وجود كتلة حرجة من الدعم مفيد جدًا في هذا التحول من كلمات المرور إلى مفاتيح المرور.)
مشكلتي الوحيدة مع هذه الميزة هي أنها تحذف حقلي الاسم واسم المستخدم من صفحة التسجيل. هل هذا متعمد؟ لا أريد أن أجبر المستخدمين على التعمق في الإعدادات مباشرة بعد التسجيل فقط لتحديد اسم مستخدم لا يكون “user63”.
ما الذي تغير؟
تفعيل رموز تسجيل الدخول لمرة واحدة في مجتمعك
قبل التفعيل، تأكد من أن كلًا من 
ما رأيك؟
