تسجيل حساب أسهل باستخدام رموز البريد الإلكتروني

[rishabh]

يمكن لمجتمعات Discourse الآن السماح للمستخدمين بتسجيل الدخول باستخدام رمز قصير يُرسل عبر البريد الإلكتروني بدلاً من رابط سحري، مما يوفر تدفق تسجيل دخول بدون كلمة مرور يشبه ما هو مألوف لدى العديد من منصات SaaS الأخرى، ويعمل جنبًا إلى جنب مع إعداد المصادقة الثنائية الحالي لديك.

في هذا الموضوع، سنستعرض التغييرات الرئيسية ونشارك كيفية البدء في استخدام هذه الميزة اليوم.

ما الذي تغيّر

عند تفعيل هذه الميزة، يرى الأعضاء تدفقًا أبسط:

:

1. يقومون بإدخال عنوان البريد الإلكتروني والنقر على متابعة.
2. يصل رمز مكوّن من ستة أرقام إلى صندوق الوارد الخاص بهم. يقومون بلصقه (أو كتابته)، وسيتم إرسال النموذج تلقائيًا عند إدخال الرقم الأخير.
3. إذا كان لديهم تفعيل المصادقة الثنائية (TOTP، أو رموز النسخ الاحتياطي، أو مفتاح الأمان)، فسيظهر خطوة 2FA القياسية التالية.

بعض التفاصيل الجديرة بالمعرفة: الرموز صالحة لمدة 10 دقائق، وتنتهي صلاحيتها بعد 5 محاولات فاشلة، ولا يمكن استبدالها إلا مرة واحدة.

تفعيل رموز تسجيل الدخول لمرة واحدة في مجتمعك

في الوقت الحالي، يُعتبر هذا تغييرًا تجريبيًا! قبل نشره على نطاق أوسع، نرحب بملاحظاتكم لمساعدتنا على إجراء تحسينات.

لتفعيل هذا الخيار، انتقل إلى صفحة التغييرات القادمة في منطقة الإدارة (/admin/config/upcoming-changes) وابحث عن عنصر تفعيل تسجيل الدخول المحلي عبر الرمز. حدّث حقل مفعّل لـ… لتسجيل موقعك في هذا التصميم الجديد:

قبل التفعيل، تأكد من أن كلًا من enable_local_logins و enable_local_logins_via_email مضبوطان أيضًا على true حيث لا يمكن تفعيل الميزة بدونها. إذا كنت تستخدم DiscourseConnect (enable_discourse_connect)، فلا يمكن تفعيل هذه الميزة.

بمجرد تفعيل التغيير، ستظهر مسار تسجيل الدخول بالرمز تلقائيًا.

أسماء مستخدمين عشوائية اختيارية للحسابات الجديدة

يمكنك منح الأعضاء الجدد الذين يسجلون بدون اسم مستخدم قابل للتعرف عليه في بريد إلكترونيهم اسمًا مولّدًا ودودًا مثل “QuietFalcon42” بدلاً من اسم عام مثل user1.

إذا قمت بالنقر على إظهار الإعدادات ذات الصلة لهذا التغيير القادم وتفعيل إعداد الموقع enable_random_usernames، فسيملأ خطوة إعداد الحساب الاقتراح مسبقًا ويتضمن زر نرد لتوليد اسم جديد:

قوائم الكلمات وراء الاقتراحات قابلة للضبط عبر إعدادات الموقع random_username_adjectives و random_username_nouns، مما يتيح للمجتمعات ضبطها لتناسب نبرتها أو لغتها.

ما رأيك؟

الكرة في ملعبك: نود أن نسمع ما رأيك في هذه الميزة الجديدة. ما الذي يعجبك وما الذي لا يعجبك؟ ما الذي يعمل بشكل جيد، وما الذي يمكن تحسينه؟

[darkpixlz (Pyx)]

جربت للتو على موقعي. لست متأكداً مما يظنه الآخرون، لكن هذا يبدو لي تراجعا كبيرا جداً كمستخدم لمدير كلمات المرور…

هذا المسار الجديد يلغي استراتيجية “إنشاء البريد الإلكتروني، كتابة اسم المستخدم، إنشاء كلمة المرور، والحفظ” التي دفعني مدير كلمات المرور للالتزام بها، ويجبرك على كتابة البريد الإلكتروني أولاً قبل كل شيء. لا أجد مشكلة في فكرة رمز البريد الإلكتروني (وأفضلها في الواقع، خاصة إذا كان الرمز مضمناً في موضوع البريد) لكنني أعارض بشدة إزالة حقول بيانات الحساب الأخرى. لو كنت مستخدماً لا يملك أي خلفية تقنية، لوجدت نفسي أيضاً لا أشارك بريدي الإلكتروني في حقل لا يحتوي على أي معلومات مثل هذا لأنه ليس تصميماً شائعاً. قبل أن يصبح هذا أمراً دائماً، سيكون رائعاً لو تمت إضافته مرة أخرى.

[dfabulich (Dan Fabulich)]

رموز البريد الإلكتروني، والمعروفة أيضًا باسم “الروابط السحرية”، مقبولة، لكن تشجيع المستخدمين على استخدام مفاتيح المرور (Passkeys) يجعل التجربة أفضل بكثير.

Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

إحدى أكبر المشكلات المتعلقة برموز البريد الإلكتروني هي أنها لا تؤدي الوظيفة التي يتوقعها المستخدمون في المتصفحات داخل التطبيقات، بما في ذلك متصفح Gmail داخل التطبيق.

ربما تكون المشكلة الأكثر شيوعًا التي يواجهها الأشخاص مع الروابط السحرية هي أنهم يعتقدون أنهم قد سجلوا الدخول إلى الموقع عبر متصفحاتهم العادية، لكنهم في الواقع يسجلون الدخول عبر متصفح داخل التطبيق. على سبيل المثال، قد يتلقى شخص ما رابط تسجيل الدخول إلى بريده الإلكتروني. ثم يفتح تطبيق Gmail، وينقر على زر “تسجيل الدخول إلى 404 Media”، فيقوم هاتفه بتحميل صفحة الويب. لكن هذا يقوم بتحميل الموقع في متصفح الويب الخاص بـ Gmail، وليس في متصفح Safari الأصلي.

تعالج مفاتيح المرور هذه المشكلة.

للبدء، يمكن للمواقع التي تستخدم الروابط السحرية جعل مفاتيح المرور ميزة اختيارية (Opt-in) للعملاء الذين اشتكوا من طريقة عمل روابطهم السحرية الحالية. لضمان عدم التسبب في أي مشكلات، كنوع من الإطلاق التدريجي، يمكنهم جعل هذه ميزة اختيارية بنسبة 100%.

بعد فترة قصيرة، عندما يقتنع مشغلو الموقع بأن مفاتيح المرور تساعد حقًا في حل مشكلات تجربة المستخدم المتعلقة بالروابط السحرية، يمكنهم تشجيع المستخدمين على إضافة مفاتيح المرور بعد تسجيل الدخول، مرة كل 90 يومًا تقريبًا، أو كلما سجلوا الدخول باستخدام ميزة تسجيل الدخول عبر الأجهزة المتعددة الخاصة بمفاتيح المرور. يمكن أن يكون إطار هذا التوجيه للمستخدمين على أجهزة Apple كالتالي: هل تريد تجنب الاضطرار إلى التحقق من بريدك الإلكتروني في المرة القادمة؟ قم بإعداد مفتاح مرور لاستخدام Face ID أو Touch ID لتسجيل الدخول بسرعة وأمان.

تشجيع المستخدمين على استخدام مفاتيح المرور هو نفسه تشجيعهم على استخدام مدير كلمات المرور، لأن مفاتيح المرور هي مجرد كلمات مرور تتطلب مدير كلمات مرور.

[Don]

مرحباً

أعجبني هذا النهج كثيراً! ومع ذلك، يزعجني قليلاً عدم إمكانية تغيير اسم العرض قبل اكتمال التسجيل. أعتقد أنه سيكون رائعاً إضافة خيار لتغييره أثناء العملية.

في مجتمعنا، قمت بتعطيل إعداد الموقع إعطاء الأولوية لاسم المستخدم في واجهة المستخدم، مما يعني أن الاسم الكامل/اسم العرض هو الأولوية في جميع أنحاء الواجهة. بسبب ذلك، تبدو الأسماء المخصصة تلقائياً مثل “user21” سيئة للغاية في الواجهة الأمامية إذا لم يكن لدى المستخدم خيار فوري لتخصيصها.

شكراً لك!

[pmusaraj (Penar Musaraj)]

@dfabulich

من أكبر المشكلات المتعلقة بأكواد البريد الإلكتروني أنها لا تؤدي الوظيفة التي نريدها في المتصفحات داخل التطبيقات، بما في ذلك متصفح البريد الإلكتروني داخل تطبيق Gmail.

لا يرسل هذا المسار الجديد رابطًا سحريًا. إنه يرسل الكود فقط. يبقى المستخدم على نفس الصفحة، وينسخ/يلصق الكود من بريده الإلكتروني إلى نموذج التسجيل. لذا فإن هذا النهج الجديد يساعد بالفعل في التعامل مع المتصفحات داخل التطبيقات (وهي إحدى المزايا الرئيسية لهذا التغيير).

@dfabulich

تشجيع المستخدمين على استخدام مفاتيح المرور (Passkeys)

هذا بالتأكيد شيء نود القيام به لاحقًا، في خطوة كلمة المرور أثناء التسجيل. لقد كثفت التطبيقات والمواقع الإلكترونية دعمها لمفاتيح المرور، وأستمر في رؤية تشجيع استخدام مفاتيح المرور في العديد من السياقات، لذا فمن المنطقي إضافتها إلى Discourse أيضًا. (إن وجود كتلة حرجة من الدعم مفيد جدًا في هذا التحول من كلمات المرور إلى مفاتيح المرور.)

[DomMcD (Dominic McDevitt)]

مشكلتي الوحيدة مع هذه الميزة هي أنها تحذف حقلي الاسم واسم المستخدم من صفحة التسجيل. هل هذا متعمد؟ لا أريد أن أجبر المستخدمين على التعمق في الإعدادات مباشرة بعد التسجيل فقط لتحديد اسم مستخدم لا يكون “user63”.

[kddkd (16)]

طريقة التسجيل باستخدام رمز التحقق عبر البريد الإلكتروني هي التغيير الذي كنت أتمناه دائماً!

[Moin]

بدون هذا التغيير، كان رابط “نسيت كلمة المرور” ورابط “أرسل لي عبر البريد الإلكتروني” بنفس الحجم. الآن أصبح الثاني أكبر. هل هذا مقصود؟

[Moin]

تم إصلاحه في

UX: Match font size of one-time code login link (#41879)

[rishabh]

شكرًا على ملاحظاتك، نعم، هذا متعمد كجزء من طريقة أسرع لإنشاء الحسابات.

@DomMcD

لا أريد إجبار المستخدمين على البحث في الإعدادات مباشرة بعد التسجيل فقط لتعيين اسم مستخدم لا يكون «user63».

تم أخذ ذلك في الاعتبار، نعم، نحن نستكشف أفكارًا لجعل هذه الخطوة التالية أبسط أو لتعيين أسماء المستخدمين الأولية باستخدام طريقة مختلفة.

[Moin]

أوافق. هذه الأسماء العامة تجعل التفاعل مع المستخدمين أكثر إرباكًا. بما أن المستخدمين لديهم ثلاثة أيام فقط كحد أقصى لتحديث أسمائهم افتراضيًا، أتوقع أنهم غالبًا ما سيلاحظون ذلك بعد مرور هذه الفترة، لذا يجب على فريق الإدارة الاعتناء بإعادة تسميتهم.
لقد استمتعت حقًا لأن Offering blank username suggestions rather than ‘UserN’ at signup منع حدوث ذلك هنا على meta على سبيل المثال. آخر مستخدم باسم userXXX تم إنشاؤه في 7 يناير قبل دمج هذا الإصلاح. ثم لم يظهر أي مستخدم جديد باسم userXXX حتى تم تفعيل هذه الميزة، ومنذ ذلك الحين ظهر 12 مستخدمًا جديدًا بهذا الاسم.

[Thomas_Rother (Thommie Rother)]

هذه الميزة مفيدة للغاية. تستخدم المزيد والمزيد من المنصات وظيفة “رمز الاستخدام لمرة واحدة عبر البريد الإلكتروني” لتقديم تسجيلات دخول آمنة باستخدام المصادقة متعددة العوامل (MFA)، دون الحاجة إلى وجود جهاز محدد (مع مصادق مناسب) في متناول اليد.

[rishabh]

@DomMcD

لا أريد إجبار المستخدمين على البحث في الإعدادات مباشرة بعد التسجيل فقط لتعيين اسم مستخدم ليس “user63”.

@Moin

أوافق على ذلك. هذه الأسماء العامة تجعل التفاعل مع المستخدمين أكثر ارتباكًا. وبما أن المستخدمين لديهم 3 أيام فقط افتراضيًا لتحديث الأسماء، أتوقع أنهم غالبًا ما يلاحظون ذلك بعد انتهاء المهلة، لذا يجب على فريق الدعم التدخل لإعادة تسميتها.

هل لا ترى هذه الخطوة أثناء إنشاء الحساب؟

[Moin]

هذا اقتباس غريب: يبدو وكأن DomMcD اقتبس كلامي، وهذا غير صحيح.

لم أجرب الخطوات. كنت أعلّق على ما لاحظته حول المستخدمين الجدد هنا على Meta. لا يهم إن كنت أرى حقلًا ما أثناء التسجيل. ما يجب أن أتعامل معه هو ما يفعله الآخرون بهذا الحقل.

كما أنني أتساءل عن كيفية التعامل مع الأسماء. فبينما لا يبدو أن كل مستخدم يستخدم الأسماء المُولَّدة آليًا، ألاحظ أن هناك عددًا أكبر من المستخدمين الذين لديهم اسم على شكل userXXX.

يبدو أنهم يحصلون على هذا حتى عند تغيير اسم المستخدم، مما يؤدي إلى استخدام نفس الرقم مرة بعد مرة حتى يُصبح اسم المستخدم محجوزًا، ثم يبدأ من جديد بالرقم التالي.

على سبيل المثال، 0102100988082 و mohamedasarudeen و user603 جميعهم لديهم user603 كاسم.

أعلم أنهم يمكنهم تغيير الاسم، ولكن مرة أخرى، لا يمكنني تغيير تجربتي في التفاعل معهم.

[rishabh]

شكرًا للجميع على التقارير، سيتم دمج الإصلاح قريبًا جدًا:

FIX: Stop placeholder usernames sticking after email code signup (#42796)

[rishabh]

تحديث

بفضل أحدث عمل من @keegan، أصبح لدينا الآن ميزة لتوليد أسماء المستخدمين في هذه الخطوة، تقوم بتعبئة اقتراح مسبقاً:

@rishabh

أسماء مستخدمين عشوائية للحسابات الجديدة

يتم الآن منح الأعضاء الجدد الذين يسجلون بدون اسم مستخدم يمكن التعرف عليه في بريداتهم الإلكترونية اسماً مولّداً ودوداً مثل «QuietFalcon42» بدلاً من اسم عام مثل user1. تقوم خطوة «الحساب جاهز» بتعبئة الاقتراح مسبقاً وتشمل زر نرد لرمي نرد جديد.

قوائم الكلمات خلف الاقتراحات قابلة للضبط عبر إعدادات الموقع random_username_adjectives و random_username_nouns، مما يتيح للمجتمعات ضبطها لتناسب نبرتها أو لغتها. للخروج من هذه الميزة والاحتفاظ بالاحتياطي الرقمي القديم، عطّل enable_random_usernames.

[Jagster (Jakke Flemming)]

طلب واحد يتعلق بتجربة المستخدم، إذا كان ذلك ممكنًا. وهو هذا:

أجهزةي متأكدة تمامًا أنني بحاجة إلى كلمة مرور هنا، لكن يجب أن تطلب البريد الإلكتروني. عندها ستعرف هاتفي وغيرها من الأجهزة أن تعرض عنوانًا بريدًا إلكترونيًا بدلاً من بيانات اعتماد أخرى.

[thisisjoshjones (Joshua Jones)]

هل يمكن تنفيذ هذا تدفق التسجيل في صفحة هبوط الدعوات أيضًا؟ أنا متأكد من أن هذا يتجاوز نطاق مرحلة ألفا الحالية، لكن هذا التنفيذ سيكون مفيدًا جدًا بعد استقرار الميزة. هذا يقلل حقًا من عتبة الدخول لأعضاء مجتمعي، فشكرًا لك!

[mcwumbly (Dave McClure)]

وبشكل مصادفة، هناك بعض الأعمال الجارية في هذا الاتجاه هنا:

https://github.com/discourse/discourse/pull/43138

[ecki (Bernd)]

أعجبني هذا المبدأ بشكل عام (خطوة التسجيل الأولى التي تعتمد على البريد الإلكتروني والرمز فقط)، لكن هناك بعض النقاط التي تحتاج إلى تحسين:

أ) يجب أن تكون إعدادات تسجيل الدخول والتسجيل منفصلة.
ب) إخفاء حقل إدخال اسم المستخدم في نموذج التسجيل يجب أن يكون خيارًا إضافيًا، لأن أسماء المستخدمين لا تزال وسيلة مهمة للتواصل، والأسماء العشوائية أو المبنية على عداد تبدو غريبة بعض الشيء.
ج) بشكل غريب، عملت الأسماء العشوائية على موقعي لبعض عمليات التسجيل غير المرغوب فيها (دخول مستخدمين غير موثقين)، لكنها لم تعمل مع مستخدمين حقيقيين، حيث حصل كلاهما على اسمي “user1” و"user2"، يا للتعاسة. (لست متأكدًا مما هو الفرق بين المزعجين والمستخدمين).
د) هل يمكن أن يكون تسجيل الدخول عبر زر إضافي، ربما زر يرسل بريدًا إلكترونيًا يحتوي على رابط سحري ورمز؟ لا أرى حاجة لفصل هذا الأمر.
هـ) يجب أن توضح الوثائق أنه يُزيل حقل اسم المستخدم (أو الأفضل ألا يزيله).