Be an admin on an up-to-date Discourse site with one or more two-factor keys enabled, such as security keys and authenticator app.
Be able to log in and out successfully with those two-factor keys.
Ensure that the site setting for enforcing two-factor logins is set to “no”.
Delete all of the two-factor items from your (admin) account using the standard UI tools in the Security tab of the admin’s user profile preferences.
Log out.
Expected behavior
Log in to site with username or password; access granted; or
Log in to site with “email me a link”; access granted.
Actual behavior
Both “expected” scenarios fail with an error message, and login is not allowed:
The selected two-factor method is not enabled for your account.
There is no further way to log in with the admin’s account.
It is worth noting that I am not actually locked out of the site in question; I had another session still active on another computer and was able to go over to that session and re-add a token-based authenticator to get back in. However, had I not had another session I would have been “fully” locked out.
Thanks for reporting this. I’ve had it bookmarked for the past few days, but haven’t got around to testing it yet. I assume that what you’re reporting is correct, but will take a close look at it next week.
I guess this is the bug? We should not allow that if your site setting says that all admins must have 2fa enabled.
I think you are not fully locked out, you can use the console to recover now, but we should not make it easy for you to create a pathological situation.
I’m not quite sure that’s the right logic? I didn’t have enforce second factor on anything but the default value of “no” and it’s not really safe to assume that every installation has more than one admin account. It seems that once the 2FA keys are removed from the profile, some other flag is not being removed somewhere…
I think you are not fully locked out, you can use the console to recover now
I suppose this is a valid emergency workaround although it may be beyond the skills of an admin who does not also manage their server and they might have to track down a sysadmin.
إذا لم يُسمح للمستخدم بتسجيل الدخول مرة أخرى بعد حذف هذا المصادقة الثنائية (آخر مصادقة ثنائية لديهم والمصادقة الثنائية مطلوبة للحساب وفقًا لإعدادات مستوى الثقة / إعدادات المسؤول)
أعتقد أنني تعرضت لنفس الخطأ (إصدار Discourse 2.7.10، تم الترقية اليوم).
تم منحني حقوق المسؤول، وقمت بتمكين المصادقة الثنائية. لاحقًا، أنشأت مستخدمًا ثانيًا لنفسي من بريد إلكتروني مختلف لاستخدامه حصريًا للمسؤول، ومنحت هذا المستخدم حقوق المسؤول.
ثم قمت بإزالة حقوق المسؤول من المستخدم الأصلي الخاص بي، وحذفت جميع طرق المصادقة الثنائية. الآن يحصل المستخدم الأصلي الخاص بي على سلوك الخطأ الذي ذكره OP.
ليس لدي وصول إلى وحدة التحكم على هذا الخادم. الموقع لا يفرض المصادقة الثنائية للمسؤولين.
هل يمكن لأحد أن يوضح ما الذي يجب فعله بالضبط في وحدة التحكم لإصلاح هذه المشكلة.
بالمناسبة، الأسباب التي دفعتني لفعل ذلك هي أنني أريد أن أخضع للأذونات والإشعارات العادية (أو لا) للمجموعات الخاصة على الموقع عبر المستخدم العادي الخاص بي، ربما مع تفعيل وضع القائمة البريدية. لا أحتاج إلى الاحتكاك الإضافي للمصادقة الثنائية كمستخدم عادي.
بالطبع، يمكن للمستخدم المسؤول رؤية كل شيء، لذا يعتمد الأمر على الثقة في عدم تجسسهم دون داع. يمكن لهذا المستخدم ترك جميع الإشعارات معطلة، وعدم تمكين وضع القائمة البريدية.
@sam تقول بشكل مغرٍ أن هذه المشكلة يمكن حلها عبر وحدة التحكم، دون ذكر ما يجب القيام به على وجه التحديد. سأقدر حقًا توجيهًا حول كيفية إصلاح هذه المشكلة بالذات.
أشك في ذلك، حيث أن الحساب لديه بالفعل المصادقة الثنائية معطلة، أو بشكل أكثر دقة، قد تمت إزالة جميع طرق المصادقة الثنائية من حسابه (تظهر المصادقة الثنائية كـ “لا” في الملف الشخصي)، ومع ذلك لا يزال تسجيل الدخول يحاول استخدام المصادقة الثنائية.
هذا الدليل مخصص لمستخدم لديه المصادقة الثنائية ممكّنة ولكنه فقد/نسي وسائله لتوليد رمز صالح.
الحل: بصفتك مسؤولاً، قم بزيارة صفحة تفاصيل المستخدم الذي تم حظر وصوله، وقم بالتمرير إلى الأسفل وانقر على زر انتحال الشخصية الأحمر.
بعد ذلك، في تفضيلات المستخدم، أضف طريقة مصادقة ثنائية (2FA). (تحتاج إلى كلمة مرور المستخدم للقيام بذلك)
يجب تقديم سر المصادقة الثنائية (2FA) للمستخدم الذي تم حظر وصوله.
في هذه الحالة، أنا كلا المستخدمين، لذا فهي ليست مهمة صعبة
هل يؤدي إزالة المصادقة الثنائية (2FA) بالضغط على زر “تعطيل الكل” إلى سلوك مختلف عن إزالة طريقة المصادقة الثنائية الأخيرة؟ أي، هل يؤدي الضغط على هذا الزر إلى إزالتها دون قفل الحساب؟
لقد تمكنت من إعادة إنتاج هذا وإيجاد حل باستخدام وحدة التحكم.
التكرار يختلف قليلاً عن كيفية وصفه في المنشور الأول. الخطوة 2 حاسمة، والخطوات 3 و 4 أقل أهمية.
كن مستخدمًا (ليس مسؤولاً) على موقع Discourse محدّث مع تمكين مفتاح أو أكثر من مفاتيح المصادقة الثنائية، مثل مفاتيح الأمان وتطبيق المصادقة.
تمكين رموز النسخ الاحتياطي
كن قادرًا على تسجيل الدخول والخروج بنجاح باستخدام مفاتيح المصادقة الثنائية تلك.
تأكد من أن إعداد الموقع لفرض تسجيلات الدخول بالمصادقة الثنائية مضبوط على “لا”.
احذف جميع عناصر المصادقة الثنائية (تطبيقات المصادقة ومفاتيح الأمان) من حسابك (ليس مسؤولاً) باستخدام أدوات واجهة المستخدم القياسية في علامة التبويب “الأمان” في تفضيلات ملف تعريف المستخدم (ليس مسؤولاً).
تسجيل الخروج.
ما يحدث هو أنه إذا تمت إزالة جميع عناصر المصادقة الثنائية، فإن رموز النسخ الاحتياطي لا تزال موجودة في قاعدة البيانات، ولا يُنظر إلى المصادقة الثنائية على أنها معطلة عند تسجيل الدخول.
نظرًا لعدم وجود تطبيق مصادقة أو مفتاح أمان بعد الآن، لا يمكن للمستخدم استخدام رموز النسخ الاحتياطي.
بمجرد إزالة جميع تطبيقات المصادقة والمفاتيح، لا يمكن حتى إزالة رموز النسخ الاحتياطي في “الملف الشخصي - الأمان”.
الحل المقترح: عند إزالة آخر عنصر أمان من المستخدم، يجب إزالة رموز النسخ الاحتياطي أيضًا.
الحل البديل: إزالة جميع سجلات UserSecondFactor لهذا المستخدم من قاعدة البيانات.
لدي نفس المشكلة مع مستخدم يشتكي من عدم قدرته على تسجيل الدخول. كان هذا المستخدم قد مكّن المصادقة الثنائية (2FA) على حسابه في وقت ما، ولكنه أزالها لاحقًا. رسالة الخطأ التي يحصل عليها عند محاولة تسجيل الدخول هي:
طريقة المصادقة الثنائية المحددة غير ممكّنة لحسابك.
من قائمة المسؤول، أرى أن ملف تعريف المستخدم يسرد “المصادقة الثنائية” كـ “لا”.
نظرًا لأنه من غير اللائق طلب كلمة مرور المستخدم، حاولت تغيير بريده الإلكتروني، أو إضافة بريد إلكتروني ثانوي أتحكم فيه. ومع ذلك، بعد النقر على “تأكيد” على رابط البريد الإلكتروني للتأكيد، أحصل على هذا الخطأ:
طريقة المصادقة الثنائية المحددة غير صالحة.
… ولم يتم تغيير/إضافة البريد الإلكتروني.
ليس لدي وصول إلى وحدة التحكم أو قاعدة البيانات لتثبيت Discord هذا لأنه “مُدار”.
هل هناك أي شيء آخر يمكنني تجربته؟ أم أن المستخدم محظور من حسابه إلى الأبد؟
هذا فظيع.
ليس لدي وصول إلى وحدة تحكم discourse، لأن هذه نسخة discourse “مستضافة”.
يحتاج المسؤولون إلى أن يكونوا قادرين على مسح المصنع 2FA من واجهة المسؤول، فمن غير المهني للغاية أن نطلب من مستخدمينا كلمات المرور الخاصة بهم.
هذه بالتأكيد مشكلة كبيرة تحتاج إلى حل. كيف يمكننا الإبلاغ عن ذلك رسميًا وتتبع تقدم إصلاح هذه المشكلة؟
كمشروع مفتوح المصدر مع نسخة discourse مستضافة، لا يمكنني الوصول إلى وحدة التحكم أو قاعدة البيانات، لدي فقط واجهة المسؤول.
في الواقع، أنا أختلف. عند تعطيل المصادقة الثنائية، يجب تجاهل رموز النسخ الاحتياطي للمصادقة الثنائية تمامًا ولا ينبغي أن تكون ذات أهمية على الإطلاق.
من خلال إصلاح هذا في المكان الخطأ (عند إزالة آخر طريقة للمصادقة الثنائية، قم بإزالة رموز النسخ الاحتياطي)، لا يزال لدينا أشخاص غير قادرين على تسجيل الدخول وقد استسلموا ببساطة دون الإبلاغ.
من خلال إصلاح الخطأ الفعلي (مع الأخذ في الاعتبار رموز النسخ الاحتياطي عند تعطيل المصادقة الثنائية)، نقوم بإصلاح هذا لـ 100٪ من المستخدمين المتأثرين، على الفور، بدلاً من مجرد التأكد من أن هذا لا يحدث باستمرار لمستخدمين جدد.
لقد نجح الأمر معي، فقد أعطاني المستخدم كلمة المرور.
يجب عليك عدم تعطيل المصادقة الثنائية (2FA) مباشرة، بل يجب عليك أولاً:
إزالة جميع رموز النسخ الاحتياطي للمصادقة الثنائية (2FA)
التحقق ثلاث مرات من إزالة جميع رموز النسخ الاحتياطي للمصادقة الثنائية (2FA)
فقط بعد ذلك قم بتعطيل المصادقة الثنائية (2FA)
باستخدام هذه الطريقة، يمكنك بالفعل تعطيل المصادقة الثنائية (2FA). هذا صحيح لكل من المستخدمين المسؤولين الذين ينتحلون شخصية المستخدمين لإصلاح ذلك، ولكنه صحيح أيضًا لكل مستخدم عادي يريد فقط تعطيل المصادقة الثنائية (2FA).
