تم اختراق حساب أحد المستخدمين لدينا. وكان سير العمل للتخفيف من ذلك بعيداً عن المثالية.
تم استخدام وحدة تحكم rails من أجل:
فرض تغيير عنوان البريد الإلكتروني
فرض تغيير كلمة المرور إلى شيء عشوائي لإجبار المستخدم على إعادة تعيين كلمة المرور عبر البريد الإلكتروني
إنهاء جميع الجلسات النشطة
علاوة على ذلك، وجدنا أن تغيير البريد الإلكتروني كان مرئياً فقط في سجلات البريد الإلكتروني الصادرة وليس في أي مكان آخر.
اكتشف كاشف البريد العشوائي بالذكاء الاصطناعي هذا البريد العشوائي للحسابات الجديدة، ولكنه لم يكن مفعّلاً لمستوى الثقة وعدد المنشورات هذا. ربما تكون فكرة جيدة تضمين خيار تمكين كاشف البريد العشوائي بالذكاء الاصطناعي لتغيير البلدان و/أو عدم وجود منشورات لأكثر من عام.
شكراً لكم جميعاً على البرنامج الرائع على مر السنين، على الرغم من العيوب الطفيفة مثل هذا.
إن تغيير البريد الإلكتروني يرسل مطالبة تأكيد إلى البريد الإلكتروني الجديد، ولكنه لا يزيل البريد القديم على الفور.
قد يكون زر إلغاء تنشيط الحساب صحيحًا، ولكنه غير مُصنف بوضوح حول ما إذا كان يفرض إعادة تعيين كلمة المرور عبر البريد الإلكتروني.
لم أتمكن بعد من العثور على زر إنهاء جميع الجلسات، وبالنسبة لتغيير كلمة المرور عبر انتحال الشخصية (impersonate) يعمل نظريًا، ولكنه فوضوي حقًا خاصة عندما تكون حسابات المستخدمين مضبوطة على لغة لا يتحدثها المسؤول/المشرف.
إذا كانت لديك أسباب معقولة تشير إلى اختراق بريد إلكتروني للمستخدم، مما أدى بدوره إلى اختراق حسابه في ديسكورس، فيمكنك، كمسؤول، تغيير بريده الإلكتروني وإزالة البريد الإلكتروني القديم.
يمكنك ببساطة وسم الحساب على أنه معطل مما سيجبر على إعادة التحقق من البريد الإلكتروني وإلغاء جميع الجلسات الحالية بشكل فعال.
لا، لقد جربت ذلك ولم أتمكن من القيام به لأنه تم إنشاء بريد إلكتروني تأكيدي للعنوان الجديد، وحتى تم النقر عليه، كان العنوان القديم لا يزال في قاعدة البيانات ومن المحتمل أن يكون صالحًا.
لست متأكدًا تمامًا من أن هذا خطأ. هذا ليس حتى حالة حافة في رأيي. لا يعد إهمال المستخدمين لبياناتهم أو هويتهم أمرًا شائعًا وهناك آليات حماية كافية. إن جعل هذه العملية أسهل قد يكون له آثار جانبية أكثر. هذا ليس شيئًا يجب على الناس التعامل معه يوميًا وإذا كان الوضع حرجًا بما فيه الكفاية، فإن المسؤولين يعرفون طرقهم للتخفيف من آثاره. ربما يمكن تحسين النص قليلًا ولكن بالتأكيد ليس لصالح إضافة المزيد من الخيارات إلى واجهة المستخدم.
لقد قدمت مؤخرًا طلب ميزة لمزيد من التحكم في عناوين البريد الإلكتروني للمستخدمين للمسؤولين، والذي سيعالج أيضًا حالة الاستخدام هذه:
نعم، ليس حدثًا شائعًا (لحسن الحظ). ولكنه حرج عندما يحدث (أو شيء مشابه)، ويتطلب استجابة سريعة. ليس الوقت المناسب لتعلم كيفية التنقل في Bash / وحدة تحكم rails أو رفع تذكرة دعم!
ولكن إلغاء تنشيط الحساب في هذه الأثناء لا يتطلب التنقل في وحدة تحكم rails. في ما يقرب من 10 سنوات من إدارة مجتمعات ديسكورس (Discourse) المختلفة، لم أواجه موقفًا كان سيتطلب وحدة تحكم rails (باستثناء ترحيل المجتمعات أو إجراء إجراءات مجمعة). أقدر حقيقة أنه قد تكون هناك حالات يعتبر فيها إجراء تغييرات مباشرة على قاعدة البيانات هو الخيار الأكثر أمانًا لمنع المزيد من الضرر، ولكن لست متأكدًا مما إذا كان إضافة المزيد من الخيارات إما إلى ملفات تعريف المستخدمين أو صفحات المسؤول منطقيًا نظرًا لأن كليهما مزدحم بالفعل كما هو.
أنا متأكد أيضًا من أن الدمج الذي يفرضه المسؤول للحسابات مع الحذف اللاحق لعنوان البريد الإلكتروني المسيء (الذي لم يعد أساسيًا) سيكون فعالاً - ويمكن استخدامه أيضًا لفرض تغييرات البريد الإلكتروني في حالات أخرى. لكن هذا يعتبر حلاً بديلاً إلى حد كبير.