مرحبًا!
أرغب في تغيير أذونات مجموعات المستخدمين، على سبيل المثال:
مجموعة المسؤول - جميع الأذونات
المسؤول المساعد - يمكنه القيام بأي شيء باستثناء فتح بعض الأقسام في لوحة الإدارة
كيف يمكنني فعل ذلك؟ شكرًا!
هذا غير ممكن افتراضيًا لأن المشرفين لديهم وصول غير مقيد إلى جميع أقسام المنتدى. اعتمادًا على نوع الأذونات التي ترغب في سحبها، قد يكون تخفيض رتبتهم إلى مشرف مساعد مفيدًا؟
لا يمكن للمشرف إنشاء فئات، وأرغب في ذلك
يمكن للمحررين إنشاء فئات إذا قمت بتفعيل إعداد moderators_create_categories في لوحة إدارة Discourse.
أين يمكنني العثور على ذلك؟ لقد تفحصت جميع الفئات في لوحة الإدارة ولم أرَ أي شيء يمكنني تعيينه للمراقبين.
*هل يوجد شيء مثل moderators_create_themes؟
انتقل إلى الإدارة > الإعدادات
ثم ابحث عن الكلمة الرئيسية moderators_create_categories
هل نظام Discourse الخاص بك محدث؟
ما تسأل عنه هو: “هل يوجد شيء مثل ‘يمكن للمراقبين إسقاط الموقع بالكامل عن طريق إنشاء سمة معطّلة؟’”. أنا متأكد إلى حد كبير أن الإجابة ستكون “لا”.
يمكنك تثبيت سمة عن بُعد مستضافة على GitHub يمكن للمراقب تعديلها، لكن سيظل على المسؤول سحب التغييرات.
أنت لا تعرف من سيقوم بالتعديل على السمات، فكيف يمكنك إبداء هذا الرأي؟
لقد طرحت هذا السؤال لأنه لا توجد مجموعات بقواعد مخصصة كما هو مذكور أعلاه.
نقطة جوهرية هي أنه إذا كنت تثق بشخص ما لدرجة تسمح له بتغيير السمات، فيمكنك تعيينه كمسؤول.
إذا كنت ترغب في السماح لغير المسؤولين بتعديل السمات أو تغيير ما يمكن للمراقب فعله، فستحتاج إلى إضافة مخصصة.
ليس في سيناريوهي الحالي. لدينا فرق تجربة المستخدم والتصميم وهم مسؤولون فقط عن هذا المجال، لذا فإن الوصول إلى السمات فقط هو المطلوب.
لدينا أيضًا حالة استخدام مماثلة. لدينا مقاولون خارجيون (مصممو ويب) نود منحهم الوصول إلى هذا. فمدير النظام الكامل سيكون لديه وصول إلى كل شيء، بما في ذلك مناقشات الإدارة الخاصة، وهو أمر غير مرغوب فيه.
سيكون من الجيد وجود سير عمل يسمح لمصممي الويب بتقديم أو تجربة التغييرات دون الحاجة إلى وصول كامل كمدير للنظام.
مرحبًا @Joaquin_Menchacha
شكرًا لك على منشورك وتذكيرك بهذا الموضوع.
نحن أيضًا نأمل (نخطط) لتحسين بعض عناصر التحكم الإدارية في المستقبل.
على سبيل المثال، نحن مهتمون بإضافة مكون إضافي (في يوم من الأيام) سيتم تكوينه باستخدام متغيرات في ملف حاوية yml، وسيحد من بعض الإجراءات الإدارية (مثل تنزيل نسخة احتياطية كاملة من الموقع) لعدد معين من المستخدمين (معرفات المستخدمين) فقط.
هذه الفكرة الخاصة بالمكون الإضافي “موجودة على قائمة أولوياتي”، وعندما أجد الوقت، سأقوم بدراسة الأمر بشكل أعمق. حتى الآن، لم أقوم حتى بالخطوة الأولى المتمثلة في فحص الكود وفحص جدوى هذه الفكرة.
هل وجد أحد حلًا هنا؟
لدي نفس حالة الاستخدام حيث أرغب في منح بعض أعضاء طاقمي إمكانية الوصول إلى السمات والإعلانات الداخلية.
الحل السهل هو الثقة بالناس ومنحهم صلاحيات المسؤول أو المشرف. إذا لم تكن تثق بهم مع التحكم الكامل، ولكنك تريد منحهم وصولاً إضافيًا، فستحتاج إلى إضافة.
الأمر لا يعني أنني لا أثق بهم. ولكن عندما يتعلق الأمر بنموذج التهديد لدينا، فإن ذلك يخلق سطح هجوم إضافي. ماذا لو تم اختراق مستخدم معين بسبب نقص الأمان من جانبه؟ هناك العديد من المتغيرات المتداخلة.
سنتناول خيار إضافة المكونات الإضافية بعد ذلك.
أتفق على أن Discourse يحتاج إلى ضوابط إضافية للتخصيص. مثلما ذكر آخرون، يمكن توظيف مقاولين خارجيين لاستخدام وظائف متقدمة مع الحفاظ على حماية معلومات الأعضاء.
الإدارة الجماعية جيدة، لكن في بعض الأحيان قد ترغب في الحصول على بعض الوظائف المتقدمة المتاحة للمدير الكامل دون الحاجة إلى جميع صلاحياته.
قد يكون إضافة مكون إضافي مفيدًا بالفعل. ولكن كما تم دمج مكون ‘دمج المستخدمين’ في النواة الأساسية، فيجب دمج ميزات مخصصة أقوى للمديرين والمشرفين للسماح بأنواع إضافية من الموظفين.
أتفق مع الآخرين هنا أن نموذج التحكم في الوصول سيتحسن بإضافة طبقة إضافية من تفصيل التحكم في الوصول القائم على الأدوار (RBAC) تحدد ما يمكن لـ staff وadmin الوصول إليه (لوظائف معينة، وليس جميعها).
على سبيل المثال، قد يرغب موقع ما في إضافة المزيد من المدراء؛ لكنهم يفضلون منح مجموعة أصغر من امتيازات RBAC للمدراء؛ مثل منح أو عدم منح القدرة على تنزيل نسخة احتياطية كاملة للموقع أو الوصول إلى ملفات سجل إجراءات معينة للموظفين. بالإضافة إلى ذلك، قد يرغب الموقع في التأكد من أن بعض الموظفين ليس لديهم أذونات RBAC لعرض إجراءات المدراء أو المطورين، أو فقط إجراءات معينة تعتبر أكثر “خصوصية”.
يتم تعليم جميع خبراء الأمن السيبراني (ويعرفون من خلال الخبرة المباشرة) أن أكبر تهديد لأي منظمة هو “الموظف غير الراضي” وليس المتسللين أو المهاجمين الخارجيين. لا شك في هذا الخطر الأساسي لأمن تكنولوجيا المعلومات، وهو معرفة راسخة للمحترفين المدربين أو ذوي الخبرة في مجال أمن تكنولوجيا المعلومات. لذلك، فإن تجاهل تهديد الداخل بـ “ثق فقط في مدير الموقع” أو “يجب أن تثق بموظفيك” ليس حلاً تقنيًا للمحترفين في مجال تكنولوجيا المعلومات. حتى أكثر الموظفين موثوقية، المخلصين لسنوات عديدة، قد يبدأون في مواجهة مشاكل حياتية قد تجعلهم يتحولون إلى “موظف غير راضٍ”. بالإضافة إلى ذلك، فإن الموظفين الأكثر امتيازًا هم من يرتكبون معظم الأخطاء؛ ونحن جميعًا نعلم أن أخطاء الموظفين/المدراء ذات النوايا الحسنة عادة ما تسبب توقفًا عن العمل أكثر من أي متسلل، بشكل عام.
منذ فترة، فكرت في تعديل class Guardian في Discourse لموقعنا، ولكن بعد فحص أعمق لتلك الفئة، لم يكن واضحًا بالنسبة لي وجود “حل سريع” يسمح لي بكتابة كمية قليلة من كود التصحيح (monkey patch) لتعزيز RBAC في Discourse. وبما أنني كسول بطبعي وأفضل إنشاء حلول بسيطة كلما أمكن، فقد وضعت الفكرة جانبًا وانتقلت إلى مشاريع أخرى “مدفوعة الأجر جيدًا”.
بعد ذلك، فكرت في النزول مستوىً آخر في الكود ونقل بعض وظائف staff وadmin إلى ```developer``، لكن هذا النهج تطلب عددًا كبيرًا من التصحيحات (monkey patches)، وهو ما اعتقدت أنه ليس فكرة جيدة في ذلك الوقت. بعد كل شيء، إذا كان بإمكاننا تحقيق شيء ما بتصحيح واحد مقابل عشرة، فمن الواضح أن التصحيح الواحد أفضل.
لم أجد بعد الوقت أو “الضرورة الملحة” للنظر بعمق في هذا الجزء من نواة Discourse لتحديد ما إذا كان هناك تحسين RBAC “سهل” يمكنني كتابته عبر ملحق “نسبيًا بسيط”.
بصراحة، أعتقد أن المشكلة هي أنني لست بعد خبيرًا في Ruby، ومعظم الوقت أعتبر نفسي مجرد “طامح” لكتابة كود Ruby، LOL. أنا واثق من أنه، على الأرجح، يوجد حل بسيط لملحق RBAC، لكن شخصيًا، لم أجد بعد، وربما يمكن لشخص Ruby أكثر خبرة بكثير النظر في الكود بسرعة ورؤية كيفية التعامل مع هذا الأمر.
فكرتي هي وجود بعض إعدادات الموقع الجديدة من نوع boolean التي إما أن تحد أو تمنح أذونات RBAC محددة بناءً على الدور، ثم إضافة هذه القيم boolean إلى الجزء المناسب من الكود عبر تصحيح (monkey patch) في الملحق. ومع ذلك، وكما ذكرت، أفضل تصحيح ملف واحد، وليس “العديد”، ليكون الأمر نظيفًا وبسيطًا وسهل الصيانة.
عندما أجد الوقت، سأبحث في هذا التحسين RBAC بشكل أعمق لأنه مثير للاهتمام بالتأكيد.
مرحبًا @jrgong
هذا ليس بالأمر الصعب تنفيذه عبر إضافة، كما أنك على الأرجح تدرك جيدًا.
بشكل أساسي، يمكنك إنشاء قائمة بالطاقم (عبر البريد الإلكتروني، اسم المستخدم، إلخ) كإعداد عام، مشابهًا لكيفية تعريف ديسكورش للمطورين عبر عنوان البريد الإلكتروني.
ثم يمكنك استخدام هذا الإعداد العام GlobalSetting في بعض التصحيحات للسماح بحالتَي الاستخدام اللتين تهتم بهما.
حالة الاستخدام الأولى: تخصيص السمات كطاقم، هي أمر مباشر نسبيًا لتنفيذه عبر التصحيح المخصص للنواة (core monkey patch)، أعتقد.
أما حالة الاستخدام الثانية، فبدون الكثير من الجهد، يمكنك نسخ إضافة discourse-adplugin وإعادة تصميم قيد الوصول للمسار في هذه الإضافة (وأي تغييرات أخرى مطلوبة):
بما أن قيد إضافة الإعلانات مدمج داخل الإضافة نفسها، فمن الجيد فعليًا تعديل هذا الكود للسماح لطاقمك “المصرّح لهم” بالوصول إلى أجزاء من تلك الإضافة التي ترغب في إجازتها، بناءً على نظام التحكم في الوصول القائم على الأدوار (RBAC) الخاص بك.
بمعنى آخر، كلا المتطلبين اللذين تريدهما قابلان للتنفيذ إذا كنت مستعدًا لكتابة الكود؛ أو بالطبع يمكنك طلب مساعدة أحد محترفي تطوير إضافات ديسكورش الماهرين في قناة Marketplace.
شكرًا لك @neounix، أقدر مدخلاتك كثيرًا! سأطلب من مطور إنجاز الأمر.
تعديل: هل لا توجد طريقة أخرى سوى إنشاء نسخة مشتقة من الإضافة؟
وماذا عن الوصول إلى إضافة دردشة باببل؟ هل يتطلب ذلك أيضًا إنشاء نسخة مشتقة؟
نحن نتحدث عن البرمجيات.
هناك دائمًا طرق عديدة للقيام بالأشياء.
لقد قدمت لك توصياتي.
