Привет!
Я хочу изменить права доступа для групп пользователей, например:
Группа администраторов — все права
Со-администратор — может делать всё, но не может открывать некоторые разделы в панели администратора
Как это сделать? Спасибо!
По умолчанию это невозможно, так как у администраторов есть неограниченный доступ ко всем разделам форума. В зависимости от того, какие именно права вы хотите отозвать, возможно, поможет понижение их до уровня модератора?
Модератор не может создавать категории, а мне это нужно.
Моды могут создавать категории, если вы включите настройку moderators_create_categories в админ-панели Discourse.
Где это найти? Я просмотрел все категории в панели администратора и не нашел ничего, что можно было бы назначить модераторам.
*Есть ли что-то вроде moderators_create_themes?
Перейдите в раздел Администрирование > Настройки
Затем выполните поиск по ключевому слову moderators_create_categories
Ваш Discourse обновлён?
Вы спрашиваете: «Существует ли что-то вроде «модераторы могут обрушить весь сайт, создав нерабочую тему»?». Я почти уверен, что ответ будет «Нет».
Вы можете установить удалённую тему, размещённую на GitHub, которую сможет изменять модератор, но для применения изменений всё равно потребуется действие администратора.
Вы не знаете, кто будет возиться с темами, как вы можете делать такие заявления?
Я задал этот вопрос, потому что групп с особыми правилами, как указано выше, не существует.
Моя мысль в том, что если вы достаточно доверяете кому-то, чтобы позволить ему менять темы, то вы можете сделать его администратором.
Если вы хотите разрешить пользователям без прав администратора изменять темы или влиять на то, что может делать модератор, вам потребуется специальный плагин.
Не в моей текущей ситуации. У нас есть команды UX и дизайна, и они отвечают только за свою область, поэтому им необходим доступ только к темам.
У нас есть аналогичный случай использования. У нас есть внешние подрядчики (веб-дизайнеры), которым мы хотим предоставить доступ к этому. Полный администратор имел бы доступ ко всему, включая частные обсуждения по управлению, что нежелательно.
Было бы удобно иметь рабочий процесс, который позволяет веб-дизайнерам отправлять или тестировать изменения без полного доступа администратора.
Привет, @Joaquin_Menchacha
Спасибо за ваш пост и напоминание об этой теме.
Мы также надеемся (планируем) доработать некоторые элементы управления администратором в будущем.
Например, нас интересует плагин (когда-нибудь), который будет настраиваться с помощью переменных в файле контейнера yml и будет ограничивать определенные действия администратора (например, загрузку полной резервной копии сайта) только для определенных пользователей (userids).
Эта идея плагина «на моей тарелке», и как только у меня появится возможность, я займусь ею более подробно. Пока я даже не сделал первого шага — не изучил код и не оценил реализуемость этой идеи.
Нашел ли кто-нибудь здесь решение?
У меня аналогичный случай: я хочу предоставить некоторым сотрудникам доступ к теме и к размещению собственной рекламы.
Простое решение — доверять людям и назначать их администраторами или модераторами. Если вы не готовы доверить им полный контроль, но хотите предоставить дополнительный доступ, вам понадобится плагин.
Дело не в том, что я им не доверяю. Но в контексте нашей модели угроз это создает дополнительную поверхность атаки. Что, если конкретный пользователь будет скомпрометирован из-за недостаточной безопасности на его стороне? Здесь задействовано множество переменных.
Тогда мы рассмотрим вариант с плагинами.
Согласен, Discourse нуждается в дополнительных средствах для настройки. Как уже упоминали другие, можно привлекать внешних подрядчиков для использования функций более высокого уровня, одновременно защищая информацию участников.
Модерация группами вполне хороша, но иногда вам могут понадобиться некоторые расширенные функции полноценного модератора, но не все из них.
Плагин действительно мог бы помочь. Но так же, как плагин «Объединение пользователей» был включён в ядро, так и более мощные настраиваемые функции для модераторов и администраторов должны быть добавлены, чтобы позволить создавать больше типов персонала.
Я согласен с другими участниками здесь, что модель контроля доступа была бы улучшена за счёт добавления дополнительного уровня детализации RBAC (управление доступом на основе ролей), который определял бы, к чему могут обращаться пользователи с ролями staff и admin (для определённых функций, а не для всех).
Например, сайт может захотеть добавить больше администраторов, но при этом предпочесть предоставить им более ограниченный набор привилегий RBAC; например, разрешить или запретить возможность скачивания полной резервной копии сайта или доступа к определённым файлам журналов действий сотрудников. Кроме того, сайт может захотеть гарантировать, что некоторые сотрудники не имеют прав RBAC для просмотра действий администраторов или разработчиков, или же только тех действий, которые считаются более «частными».
Всем специалистам по кибербезопасности преподают (и они знают из личного опыта), что наибольшую угрозу для любой организации представляет «недовольный инсайдер», а не внешние хакеры или злоумышленники. В этом базовом риске информационной безопасности нет никаких сомнений, и это хорошо установленный факт для подготовленных или опытных специалистов по ИБ. Поэтому отмахиваться от угрозы со стороны инсайдеров фразами «просто доверяйте администратору» или «вы должны доверять своим сотрудникам» — это не техническое решение для ИТ-специалистов. Даже самый надёжный сотрудник, работающий многие годы, может начать сталкиваться с жизненными проблемами, которые заставят его превратиться в «недовольного сотрудника». Кроме того, именно наиболее привилегированные сотрудники чаще всего совершают ошибки; и мы все хорошо знаем, что ошибки доброжелательных сотрудников или администраторов, как правило, приводят к простоям чаще, чем любые действия хакеров.
Некоторое время назад я рассматривал возможность изменения класса Guardian в Discourse для нашего сайта, но после дальнейшего изучения этого класса мне не стало очевидно, что существует «быстрое решение», позволившее бы мне написать минимальное количество кода патча (monkey patch) для улучшения RBAC в Discourse. Будучи по натуре ленивым и предпочитая создавать простые решения, когда это возможно, я отложил эту идею на потом и переключился на другие проекты для «хорошо оплачиваемых клиентов».
Позже я подумал о том, чтобы спуститься на уровень ниже в коде и перенести некоторые функции staff и admin в developer, но этот подход требовал слишком большого количества патчей (monkey patches), что, как мне показалось, не было хорошей идеей в тот момент. В конце концов, если мы можем достичь чего-то с помощью одного патча вместо десяти, очевидно, что один патч лучше.
У меня пока не нашлось времени или «острой необходимости» глубже изучить эту часть ядра Discourse, чтобы определить, существует ли «простое» расширение RBAC в виде плагина, которое я мог бы написать через «относительно простой» плагин.
Честно говоря, я думаю, что проблема в том, что я ещё не супер-рубист и в основном считаю себя скорее «wannabe»-кодером на Ruby, LOL. Я уверен, что скорее всего, существует простое решение в виде плагина для RBAC, но лично я его пока не нашёл, и, возможно, более опытный специалист по Ruby сможет быстро посмотреть на код и понять, как подойти к этой задаче.
Моя идея заключалась бы в добавлении новых булевых настроек сайта, которые бы ограничивали или предоставляли конкретные права RBAC в зависимости от роли, а затем добавлении этих булевых значений в соответствующую часть кода через патч (monkey patch) в плагине. Однако, как я уже упоминал, я предпочёл бы патчить один файл, а не «многие», чтобы это было чисто, просто и легко поддерживалось.
Когда у меня появится время, я займусь этим улучшением RBAC более глубоко, так как это, безусловно, интересно.
Привет, @jrgong!
Как вы, вероятно, хорошо знаете, это несложно реализовать с помощью плагина.
В целом, вы можете создать список сотрудников (по электронной почте, имени пользователя и т. д.) в виде глобальной настройки, аналогично тому, как Discourse определяет разработчиков по адресу электронной почты.
Затем вы можете использовать эту GlobalSetting в некоторых патчах, чтобы разрешить два интересующих вас сценария.
Первый из ваших сценариев: кастомизация тем как сотрудник, по моему мнению, относительно просто реализовать через monkey patch ядра.
Что касается второго сценария, то при небольших усилиях вы можете форкнуть этот плагин и переработать ограничение доступа к маршрутам в нём (а также внести любые другие необходимые изменения):
Поскольку ограничение для плагина рекламы встроено в сам плагин, хорошей идеей будет фактически изменить этот код, чтобы разрешить доступ вашим «разрешённым» сотрудникам к тем частям плагина, к которым вы хотите предоставить доступ, основываясь на вашей собственной модели RBAC.
Иными словами, оба ваших требования выполнимы, если вы готовы написать код; или, конечно, вы можете попросить одного из опытных профессиональных разработчиков плагинов Discourse помочь вам в канале Marketplace.
Спасибо @neounix, я очень ценю ваш вклад! Я поручу разработчику это сделать.
Редакция: Нет ли другого способа, кроме как форкнуть плагин?
А как насчет доступа к плагину Babble Chat? Это тоже потребует форка?
Мы говорим о программном обеспечении.
Всегда есть много способов сделать вещи.
Я дал вам свои рекомендации.
