تم التعديل من أجل توضيحات جوهرية ومعايير اقتراح أكثر تفكيرًا لمساعدة أعضاء المجتمع الآخرين على فهم فائدة تحسين هذه الميزة.
تحديث إعداد قابلية تحرير البريد الإلكتروني للسماح بخيارات إضافية بشأن من يمكنه تحرير عناوين البريد الإلكتروني، حيث صُمم الإعداد على سبيل المثال:
جميع المستخدمين
مستخدمون فقط [لا يمكن للمسؤولين العاديين أو المشرفين ذلك دون استخدام وحدة تحكم Rails أو تغيير الإعداد.]
طاقم العمل فقط
المسؤولون فقط
إذا كان الإعداد مفعلًا [وهو الحال افتراضيًا]، فسيتم إدخال آلية حماية بنظام وضع السوبر (Sudo-Mode) لتنفيذ الإجراء بصفتك مسؤولًا [وليس المستخدم الذي ينتمي إليه الحساب الذي يتم تحريره]؛ وهذا يسمح بإدخال هذا الإعداد مع بعض النقاط الرئيسية المذكورة أدناه لتكون محمية من التغييرات غير المرغوب فيها.
الأسباب/لماذا يجب تنفيذ ذلك
إذا أردت تعطيل الإعداد لأنك تريد السيطرة على هذا الأمر، مثل أن يطلب المستخدمون التغيير وتقوم به أنت كإجراء أمني، أو لسبب آخر، ولكنك تحتاج لسبب ما إلى تحرير البريد الإلكتروني؛ مع تعطيل هذا الإعداد، حتى المسؤولون لا يمكنهم تحرير عناوين البريد الإلكتروني.
وهنا تكمن المشكلة الجديدة إذا انطبق واحد أو أكثر من حالات الاستخدام.
لتحرير عناوين البريد الإلكتروني للمستخدمين حاليًا؛ يمكنك إما 1) تفعيله في علامة تبويب أخرى، وتحرير البريد الإلكتروني بسرعة، أو 2) فتح وحدة تحكم Rails وتغيير البريد الإلكتروني يدويًا.
بالنسبة لمعظم عمليات الإدارة اليومية العادية، قد يؤدي هذا إلى تحدي تقني غير مرغوب فيه. إذا اعتمدت فقط على فعل كل شيء في وحدة تحكم Rails، بينما الإعداد موجود بالفعل.
كيف يمكن أن تساعد الآليات الإضافية في جعل هذه الميزة حقيقة واقعة:
إذا تُرك مفعلًا بسبب أثر تقني، فقد يتم تغيير عناوين البريد الإلكتروني للمستخدمين المخترقين.
قد يرتكب المسؤولون أخطاءً أو يقومون بتغييرات غير مصرح بها.
سيشعر المستخدمون بأن الأشخاص الذين يمتلكون هذه الصلاحية محميون من التغييرات التي تتم بسوء نية.
تمت مناقشة هذا الموضوع آخر مرة في 2015، ورغم صحة أنه يمكنك تحرير عناوين البريد الإلكتروني، إلا أنك لا تستطيع تحريرها من خلال عرض المسؤول؛ بل يُخبرك بالانتقال إلى عرض تفضيلات المستخدم، وهو ما أفعله، وحتى بصفتي مسؤولًا لا أستطيع ذلك بسبب قيود هذا الإعداد.
أوافقك الرأي بشدة في هذا الشأن. فبينما قد تبدو حالتك الاستخدامية محددة وبسيطة بالنسبة لك، فإن تنفيذ تجاوز بسيط في واجهة المستخدم لهذا الغرض سيُحدث خطرًا أمنيًا كبيرًا مقابل راحة طفيفة جدًا.
الاحتكاك هو ميزة أمنية!
لذا فإن الإزعاج الناتج عن ضرورة استخدام وحدة تحكم Rails أو تبديل إعدادات الموقع على نطاق واسع هو في الحقيقة ميزة أمنية حاسمة، حيث يعمل كـ “فرامل أمنية” ويجبر المسؤول على اتباع عملية متعمدة وعالية الاحتكاك لعملية حساسة للغاية.
تغيير عنوان البريد الإلكتروني للمستخدم يعادل تسليم مفاتيح حسابه، حيث يمكن استخدام عنوان البريد الإلكتروني الجديد لتفعيل إعادة تعيين كلمة المرور، مما يؤدي فعليًا إلى حجب المستخدم الأصلي ومنح المالك الجديد للعنوان تحكمًا كاملاً.
بعض نواقل الهجوم الرئيسية التي يمنعها هذا الاحتكاك:
اختراق حسابات المسؤولين! - هذا هو الخطر الأهم. إذا تمكن مهاجم من الوصول إلى حساب مسؤول (عبر التصيد أو إعادة استخدام كلمات المرور، إلخ)، فإن وجود زر بسيط في واجهة المستخدم أو أي تبديل آخر سيسمح له بالسيطرة بصمت وسهولة على أي حساب مستخدم آخر، بما في ذلك حسابات الموظفين الآخرين؛ بينما يوفر شرط الوصول إلى سطر الأوامر عبر وحدة تحكم Rails طبقة أمان قوية.
الهندسة الاجتماعية! - هذا يفتح الباب أمام الهندسة الاجتماعية. قد يتظاهر مستخدم خبيث بأنه مستخدم شرعي ويقنع مسؤولًا بتغيير عنوان بريده الإلكتروني؛ مرة أخرى، فإن العملية الحالية عالية الاحتكاك تجعل من المرجح أن يتحقق المسؤول من صحة الطلب أو يفكر بجدية في مصداقيته.
التهديد الداخلي - قد يساء استخدام هذه الميزة من قبل مسؤول خبيث للسيطرة على الحسابات.
لهذه الأنواع من الإجراءات الإدارية النادرة وعالية المخاطر، يُعد استخدام وحدة تحكم Rails مناسبًا لأنه يضمن أن الشخص الذي ينفيذ الإجراء لديه وصول إلى الخادم وليس مجرد جلسة مخترقة. بالإضافة إلى أن الإجراء متعمد ويتطلب معرفة تقنية محددة (وهو مسجل في سجل سطر الأوامر).
أقدر اهتمامك، لكنني أعتقد أنك قد تكون أساءت فهم الصورة الكاملة هنا، بما في ذلك ثغرة خطيرة في حجتك حول “الأمان”.
يمكنك بالفعل تعديل رسائل البريد الإلكتروني إذا كان هذا الإعداد مفعلًا؛ وهو مفعل افتراضيًا.
تعريض حسابات المشرفين للخطر! - هذا هو الخطر الأهم. إذا تمكن مهاجم من الوصول إلى حساب مشرف (عبر التصيد أو إعادة استخدام كلمات المرور، إلخ)، فإن زر واجهة مستخدم بسيط أو مفتاح تبديل، سيُتيح له الاستيلاء بهدوء وسهولة على أي حساب مستخدم آخر، بما في ذلك موظفين آخرين؛ بينما يوفر شرط الوصول إلى الـ Shell عبر Rails Console طبقة أمان قوية.
إذا تم اختراق حساب مشرف، يمكن للمخترق ببساطة تفعيل الإعداد الموجود بالفعل اليوم، والقيام بالأشياء التي ذكرتها.
تغيير عنوان بريد المستخدم الإلكتروني يُعادل تسليم مفاتيح حسابه، حيث يمكن استخدام العنوان الجديد لتفعيل إعادة تعيين كلمة المرور، مما يؤدي فعليًا إلى إغلاق الوصول للمستخدم الأصلي ومنح المالك الجديد للبريد الإلكتروني السيطرة الكاملة.
لهذه الأنواع من الإجراءات الإدارية النادرة وعالية المخاطر، يُعتبر استخدام Rails Console مناسبًا لأنه يضمن أن الشخص المنفذ للعملية لديه وصول إلى الخادم وليس جلسة مخترقة. بالإضافة إلى أن الإجراء متعمد ويتطلب معرفة تقنية محددة (وهو مسجل في سجل الـ Shell).
ليس دائمًا، وكما قلت في المنشور الأول: يمكنك ببساطة تفعيل الإعداد ثم تعطيله لتمكين وظيفة التعديل، المشكلة الوحيدة هي أن تفعيل الإعداد، الذي يُفترض أن يكون معطلًا [مفعلًا افتراضيًا]، يُتيح للمستخدمين غير المشرفين تعديل بريدهم الإلكتروني أثناء إجراء تعديل بسيط.
“السماح للمستخدمين بتغيير عنوان بريدهم الإلكتروني بعد التسجيل”
هذا يتيح التعديل لجميع المستخدمين (والمشرفين). الطلب البسيط هو: السماح بتعيين الإعدادية لـ - على سبيل المثال: “المشرفون فقط، المشرفون + المستخدمون، أو المستخدمون فقط”.
إذا قمت ببساطة بـ “تفعيلها”، فإن ذلك يفعّل قدرة الموقع بأكمله على أن يقوم أي شخص [أو المشرفون] بتغيير بريد مستخدم إلكتروني. أثناء التفعيل.
تعيين إعدادية، موجودة بالفعل بشكل جزئي، لتُطبّق على المشرفين فقط يسمح بوظيفة بسيطة موجودة بالفعل بأن لا تكون مجرد سيناريو الكل أو لا شيء.
حسناً، بعد التفكير في الأمر أكثر، أعتقد أن طريقة واجهة مستخدم عالية الاحتكاك باستخدام sudo قد تكون الحل الأمثل، حيث أن هذا الإعداد يعتبر “غير آمن” في نافذة التحرير، وليس جميع المدراء يمتلكون وصولاً إلى وحدة تحكم Rails (مثل المواقع المستضافة).
ربما يمكن أن يكون الحل كالتالي: عندما يحاول مدير حفظ البريد الإلكتروني الجديد، تظهر نافذة منبثقة تجبره على إعادة إدخال كلمة مروره الخاصة لتأكيد الإجراء (أو تحدي المصادقة الثنائية 2FA إذا كان مفعلاً). ومن البديهي أن يجب تسجيل هذا الإجراء بتفاصيل دقيقة في سجلات الموظفين. أعتقد أن التحقق الإلزامي من المستخدم لا يزال ضرورياً بطريقة ما لإتاحة الفرصة للمستخدم الشرعي للإبلاغ عن اختراق الحساب، كما يجب أيضاً إرسال إشعار إلى عنوان البريد الإلكتروني الجديد لتأكيد التغيير؟
أجل، هذه الميزة بحاجة بالتأكيد إلى بعض الاهتمام والتحديثات. في الوقت الحالي، إذا قمت بتفعيلها، يمكن لأي مدير تحرير عنوان البريد الإلكتروني لأي حساب مستخدم دون وجود أي ضوابط إضافية. أعجبني فكرتك المتعلقة بالمصادقة الثنائية أو كلمة المرور.
لقد قمت بتعديل المنشور الأصلي لتحسين الصياغة بشكل كبير، وإضافة تلك الاقتراحات الإضافية حول الحذر من التغيير أعتقد أن ذلك سيحسن الأمور بشكل كبير بشكل عام.
أتساءل متى تم هذا التغيير. على مر السنين، قمت بإصلاح حسابات الأعضاء عن طريق تغيير عنوان البريد الإلكتروني بصفتي مسؤولًا. إنها طريقة مفيدة لإصلاح الحساب عندما يقوم مشرف بإخفاء هوية عضو بشكل غير نزيه أو عن طريق الخطأ.
إذن، هل يمكن إصلاح هذا في ملف app.yml لاستعادة وصول المسؤول من خلال واجهة المستخدم؟ فحسابات المسؤولين يجب أن تكون محمية بشكل صحيح إذا كان الشخص يقظًا.
ومع ذلك، يجب أن يتيح Discourse تدرجًا للمناصب الإدارية لتحقيق تحكم أدق في الوظائف الإدارية (نقاش قديم). فالحساب الإداري الأعلى مستوى مثالي للحصول على كامل الصلاحيات والتحكم. بينما قد يحتاج البعض فقط إلى الوصول إلى إعدادات المظهر.
كان هذا مصدر قلق تم طرحه عند اكتشاف ميزة “الانتحال”. بالتأكيد يمكن القول إنها قد تكون مفيدة لمساعدة المستخدمين في حل مشاكلهم. أو التبديل إلى حسابات الاختبار لاختبار الوظائف ك مستخدم عادي؛ لكن من السهل جدًا استخدام علامات التبويب أو النوافذ لتسجيل الدخول بحسابات الاختبار.
الآن، الخطوة الذكية البسيطة هي إضافة قيد أمان مشابه لنظام لينكس، بحيث تتطلب بعض الوظائف كلمة مرور إضافية للموقع لاستخدام وظيفة معينة كمسؤول. مثل تغيير عنوان البريد الإلكتروني للمستخدم.
هل إعداد الموقع email_editable مفعّل في موقعك؟ يكون مفعّلًا افتراضيًا، وبالتالي لا تكون مشكلة تغيير البريد الإلكتروني. لكن المشكلة تظهر عندما يكون هذا الإعداد معطلًا.
لقد تحققت للتو. جميع مواقع الويب الخاصة بي لا تسمح للمسؤول بالتعديل. لذا يجب أن يكون التحديث قد غيّر هذا السلوك. لم يُسمح للمستخدمين العاديين بتغيير عناوين البريد الإلكتروني، لكن بصفتي مسؤولًا، قمت بذلك في الماضي لحسابات البريد الإلكتروني المفقودة، وعندما كان لدي مشرف سيء يقوم بإخفاء هوية الأشخاص الذين اختلف معهم (تم حل هذه المشكلة لأن ذلك الشخص انتقل إلى شركة أخرى).
يجب أن يكون تغيير البريد الإلكتروني من قبل المسؤول إعدادًا منفصلًا عن تمكينه لجميع المستخدمين. حتى لو كان لا بد من تغييره في البداية عبر وحدة التحكم لتمكين المسؤول.
هذا هو السبب الذي جعل هذه الاقتراحات تبرز — لأنني لا أرغب في السماح للأعضاء بتغيير عناوين البريد الإلكتروني بأنفسهم، وأفضّل الاحتفاظ بحماية من الإدارة. لكن تعطيل هذه القدرة على تعديل البريد الإلكتروني قد طُبق على الجميع، بما في ذلك المدراء، وليس الأعضاء فقط.
في البداية، كنتُ قد اقترحتُ ببساطة السماح للمدراء بالتغيير بغضّ النظر عن الإعداد، لكن قمتُ بتعديل الاقتراح ليكون أكثر هيكلية بناءً على الردود الأولية.
أعتقد أن ذلك سيحسن الأمور بشكل كبير بشكل عام.