Стать администратором

[hellekin]

Проблема

1. Администраторы могут случайно получить доступ к конфиденциальным разделам форума.
2. Такие нежелательные доступы не фиксируются в логах.
3. Администраторы могут не заметить ошибок конфигурации, поскольку их привилегии скрывают от них обычный пользовательский опыт.

Описание функции

Аналогично функции, описанной на Impersonating a user, пользователь с правами администратора должен иметь возможность стать администратором для выполнения административных задач только тогда, когда это действительно необходимо.

В отличие от функции «Притворение пользователем», эта функция не должна требовать выхода из системы для восстановления обычных пользовательских привилегий.

Данная функция позволит:

1. Администраторам просматривать сайт как обычные пользователи, разделяя ежедневный опыт других пользователей;
2. Предотвратить случайный доступ администраторов к закрытым разделам форума;
3. Обеспечить защиту от несанкционированного доступа к таким закрытым разделам за счёт ведения фактического лога доступа администраторов.

Первый пункт важен, поскольку опыт администратора сильно отличается от опыта обычного пользователя, и администраторы могут не замечать проблем пользователей (например, связанных с неверными правами доступа, установленными для категорий или групп и т. д.).

Второй пункт может быть критически важным в случаях, когда группа требует конфиденциальности: клик по ссылке может случайно привести администратора к нарушению конфиденциальности.

Третий пункт позволит администраторам нести ответственность за несанкционированный доступ к конфиденциальным разделам форума, чего сейчас совершенно не происходит.

Как это может работать?

• Повышение привилегий должно быть доступно только реальным аккаунтам администраторов;
• «Администратор» можно рассматривать как дополнительный уровень доверия (например, уровень 5 ^[1]);
• Возврат к «обычному» режиму будет просто переключением обратно на предыдущий УД;

Вместо предоставления совершенно нового «вида администратора», режим администратора может добавлять дополнительный слой пользовательского интерфейса:

• подсветка ссылок, которые работают только потому, что вы администратор;
• подсветка категорий, к которым у вас есть доступ только потому, что вы администратор;
• подсветка членства в группах, которое вы видите только потому, что вы администратор (например, если вы являетесь членом группы с ограниченным доступом к членству в группах, подсветка не будет применяться);
• подсветка информации, которую могут видеть только администраторы.

---

1. Ссылка на фильм Криса Маркера «Уровень 5» (Level Five (film) - Wikipedia), в котором программист пытается завершить видеоигру своего покойного мужа о битве при Окинаве, чтобы преодолеть горе. ↩︎

[Moin]

Я думаю, это похоже на

"Regular mode" for admins and moderators (e.g. something like "sudo")

I’m both an admin and a participant in the Fedora discourse sites. I’d like to be able to separate those roles. I know there’s the “staff color” for Official Posts, but I mean more from my side. Rather than admin wrenches and buttons everywhere whenever I’m logged in, I’d like a menu toggle which would activate Admin Mode on and off.

[hellekin]

Я вижу, как это похоже, однако в другой дискуссии есть вопросы, связанные с проблемой здесь:

@codinghorror

часть работы администратора — понимать свою ответственность и границы, которые необходимо уважать. Если вы не можете этого сделать, вам не следует иметь права администратора.

Кроме того, когда вы администратор, у вас нет возможности увидеть, что ссылка на конфиденциальный разговор, к которому у вас обычно нет доступа, на самом деле недоступна. Это лишь один случай (который произошел у нас вчера и побудил меня начать эту тему), где отсутствие разделения между администратором и участником может стать проблемой.

Более того, я вижу, что команда Discourse имеет привычку быть полностью административной, что создает горизонтальную сверхспособность и не помогает, как культура, различать обычное использование и использование с привилегиями. Не все сообщества горизонтальны; иногда техническим специалистам, имеющим права администратора, нельзя доверять всё на форуме, и это не крайний случай: в компьютерных системах с самого начала было заложено, что root может видеть и делать всё. Привилегии, безусловно, сопряжены с ответственностью, но иногда благонамеренности недостаточно, особенно когда невозможно отличить допустимое от недопустимого.

Хотя решение «использовать другой профиль браузера» для работы с обычной и административной учетной записью существует, оно не очень практично, особенно учитывая, что все привыкли иметь инструменты под рукой. Запуск нового браузера каждый раз, когда нужны функции администратора, может быть очень раздражающим (не всем нравится или они не могут позволить себе простаивающие ресурсы на своём компьютере). Это также не предотвращает ситуацию, когда привилегированный BOFH подглядывает.

@mattdm

Я не хочу иметь возможность случайно нарушать правила тегирования. (Могут ли модераторы без прав администратора тоже случайно это сделать? Я даже не могу легко это проверить.)

Я мог бы создать отдельную учетную запись администратора и понизить свою основную до обычного пользователя, но боюсь, что пропущу важные уведомления о флагах и сообщения.

@mattdm

Ну, это отчасти то же самое, что и постоянная работа под root в системе Linux. Речь не только об уважении границ, но и о том, чтобы случайно не переступать их, не осознавая их существования.

@codinghorror

Я понимаю опасения, но на практике это не является большой проблемой

Времена меняются. Здесь у нас есть администратор, который случайно получил доступ к конфиденциальной информации, затрагивающей жизнь других людей, хотя не должен был этого делать. Это нарушение конфиденциальности. Это вопрос безопасности.

@leonardo

Хотя эта логика в основном централизована в guardian.rb и /lib/guardian/*.rb, сложность и потенциал ошибок при таком изменении были бы очень велики, и необходимость этой функции должна была бы значительно перевешивать их, чего нет, учитывая альтернативы.

Я понимаю потенциальную сложность, но основная проблема остаётся и должна быть решена тем или иным способом. На мой взгляд, стоит пересмотреть этот вопрос теперь, когда кодовая база созрела, и оценить, выполним ли предложенный подход.

@Ivan_Rapekas

Я предполагаю, что автор темы имел в виду работать большую часть времени как обычный пользователь. Для меня я тоже хочу чувствовать себя простым пользователем:

• меньше кнопок
• нет доступа к действиям модерации/администрирования
• использование простых сценариев пользователя

После обновлений или настроек я хотел бы взаимодействовать с форумом так, как его видит обычный пользователь, чтобы избежать недопонимания.

@Canapin

Это напоминает мне о случае, произошедшем несколько дней назад. Я занимаюсь миграцией форума.

Да! Предупреждения и защитные механизмы относительно таких проблем (вторжение) были бы полезны.

---

Существующие плагины:

• GitHub - discourse/discourse-anonymous-moderators · GitHub может быть полезен, но недавнее изменение, касающееся электронной почты (Enabling e-mail normalization by default), может это изменить — полагаться на отсутствие настроек по умолчанию может оказаться проблематичным.
• GitHub - discourse/discourse-staff-alias: Allow staff users to post under an alias · GitHub ограничен только публикациями.

Я бы предпочел иметь действительно чистое разделение между участником и администратором, используя классическую и хорошо известную метафору sudo, по всем причинам, указанным выше.

[Ed_S]

Я согласен, что механизм sudo (в Windows — диалоговое окно Контроля учетных записей) — это хороший способ предоставить учетной записи возможность действовать как администратор, но без постоянного наличия таких прав.

На одном из моих форумов я использую следующий подход: у меня есть вход для администратора, но обычно я использую функцию «Имперсонация пользователя», чтобы всегда работать под обычной учетной записью. Когда мне нужно действовать как администратор, я выхожу из системы и снова вхожу. Это означает наличие двух учетных записей.

Одно из преимуществ двух учетных записей заключается в том, что, публикуя сообщения или комментируя от имени обычной учетной записи, я не выгляжу как влиятельная и важная личность. (Иногда комментарии от имени администратора воспринимаются как официальное заявление или полицейское действие. Это зависит от культуры и ожиданий читателя.)

[hellekin]

Поскольку эта функция, если она когда-либо будет реализована (не забудьте проголосовать за неё!), потребует времени для появления, мы рассматриваем вариант использования двух учётных записей. Это означает: преобразование существующих учётных записей в обычные. Вот что это должно включать (я постараюсь отредактировать этот пост или сделать его вики-страницей, чтобы мы могли вести актуальную документацию с учётом всех нюансов)…

ещё не протестировано: всё это теоретические рассуждения, написанные по памяти.

Преобразование существующей учётной записи администратора Discourse в учётную запись обычного пользователя

Поскольку мы не хотим терять историю и «опыт работы на форуме» оригинальной учётной записи, необходимо действовать осторожно перед снятием привилегий администратора.

Исходные данные: пользователь me с электронной почтой original-me@email.example.

Первый случай: учётная запись администратора в DISCOURSE_DEVELOPER_EMAILS

Если электронная почта учётной записи администратора входит в список DISCOURSE_DEVELOPER_EMAILS, её нельзя понизить до уровня обычной учётной записи.

1. Создайте новую учётную запись, которая станет администратором, например, me2 с почтой original-me+admin@email.example.
2. Из учётной записи me предоставьте права администратора новой учётной записи me2.
3. Отредактируйте файл app.yml (или web_only.yml, если вы используете настройку с двумя контейнерами), заменив original-me@email.example на original-me+admin@email.example, и пересоберите контейнер.
4. Из учётной записи me2 понизьте оригинальную учётную запись me.

Теперь у вас есть учётная запись обычного пользователя со всем вашим опытом (me) и новая учётная запись только для администратора (me2): переходите к разделу «Последствия».

Второй случай: учётная запись администратора, повышенная из обычного пользователя

Это проще, так как вы можете понизить этого пользователя без необходимости пересборки контейнера.

1. Создайте новую учётную запись, которая станет администратором, например, me2 с почтой original-me+admin@email.example.
2. Из учётной записи me предоставьте права администратора новой учётной записи me2.
3. Из учётной записи me2 понизьте оригинальную учётную запись me.

Теперь у вас есть учётная запись обычного пользователя со всем вашим опытом (me) и новая учётная запись только для администратора (me2): переходите к разделу «Последствия».

Последствия

Раньше у вас была одна учётная запись с правами администратора: вы получали уведомления о системных обновлениях, проверяли флаги и могли получать доступ ко всем разделам, включая те, к которым вам не следовало иметь доступ (например, личные сообщения пользователей, если они не зашифрованы), или категории, ограниченные для групп, в которые вы не входите. Всё это исчезло! Теперь вы обязаны регулярно заходить в свою учётную запись администратора, чтобы делать всё то, к чему вы привыкли из своей уникальной учётной записи пользователя/администратора (что является ещё одной причиной, по которой предлагаемая функция полезна). Вам нужно выработать дисциплину открывать обе учётные записи одновременно, если вы хотите получать уведомления администратора в реальном времени (например, используя приватную вкладку в Firefox или аналогичную функцию в других браузерах).

Нюансы

Вам не следует использовать свою учётную запись администратора ни для чего, кроме администрирования.

Не просматривайте обсуждения, пока вы в режиме администратора! Это время теряется для вашего собственного прогресса уровня доверия, и вы никогда не знаете, когда можете случайно нажать на ссылку, которая для вас как для обычного пользователя недоступна.

Если вы случайно прочитаете что-то в учётной записи администратора, что вызовет у вас реакцию, либо переключитесь на вкладку обычного пользователя и перейдите по оригинальной ссылке, либо, если ваша обычная учётная запись не имеет доступа к этому разделу: немедленно забудьте об этом (если, конечно, вы не должны реагировать в качестве администратора).

Вам следует настроить учётную запись администратора так, чтобы она выглядела иначе

Измените аватар, чтобы вы никогда не путали учётную запись администратора и учётную запись обычного пользователя. Сделайте свой профиль невидимым. Измените фоновое изображение или тему, добавьте в имя слово «ADMIN» или фразу вроде «ЭТА УЧЁТНАЯ ЗАПИСЬ НЕ ПИШЕТ» и т.д. Просто убедитесь, что у вас нет соблазна когда-либо публиковать сообщения с учётной записи администратора.

Вам следует настроить учётную запись администратора для фильтрации уведомлений

СДЕЛАТЬ: детализировать этот раздел

Вы должны настроить учётную запись администратора так, чтобы отключить все уведомления по электронной почте (если вы не хотите получать такие уведомления, например, чтобы избежать необходимости постоянно держать открытой вкладку администратора) И чтобы вы могли чётко различать, какие уведомления предназначены вам как личности, а какие — для вашей роли администратора.

Вам, вероятно, понадобятся уведомления на рабочем столе, чтобы отслеживать флаги и важные сообщения.

Что делать с категорией персонала и шепотом?

Да, вы столкнулись с ещё одной сложной проблемой при использовании двух отдельных учётных записей для участия в качестве администратора и обычного пользователя. Иногда вы обязаны взаимодействовать на форуме в качестве администратора. Это, вероятно, неизбежно. Постарайтесь не стать шизофреником и сведите к минимуму свои вмешательства в качестве сотрудника. Пожалуйста, делитесь своими тактиками решения этой трудной задачи и мотивируйте всю команду администраторов Discourse реализовать эту функцию.

Преимущества решения с двумя учётными записями

1. Чёткое разделение между участием и администрированием (в некоторой степени)
2. Вы не можете совершать ошибки с обычной учётной записи
3. Все ваши действия администратора правильно логируются
4. Как пользователь, вы воспринимаете форум как любой другой пользователь, поэтому легко можете выявить проблемы с правами доступа
5. Если вы случайно опубликуете сообщение как admin, но хотели опубликовать его от своего имени, вы можете изменить владельца на другую учётную запись (но это немного противоречит идее наличия двух учётных записей).

[NateDhaliwal]

Значит, администраторы — это обычные пользователи или пользователи уровня TL4, но они могут включить «режим администратора», чтобы использовать специальные функции?
Если так, что мешает администраторам всегда держать его включённым?

[Ed_S]

@hellekin

Вам нужно выработать эту дисциплину: открывать обе учётные записи одновременно, если вы хотите получать уведомления администраторов в реальном времени.

Это интересное замечание. Есть ли способ сократить разрыв — разрешить группе управлять доставкой уведомлений без самого контента? «Есть помеченные сообщения», «Есть ожидающее сообщение», «Ваша установка устарела».

[Ed_S]

@Nate Dhaliwal

Что мешает администраторам всегда оставлять это включённым?

Вот идея: роль администратора не может публиковать сообщения в публичной категории или теме, а также не может ставить лайки сообщениям.

[Ar_D (Arpit D)]

Это также означает, что аккаунт может быть проигнорирован, как и у обычного пользователя. Получать только необходимые обновления от администратора, если мы хотим их игнорировать. Отличная работа