Это может быть связано с социальными и/или культурными факторами, и я делюсь своими мыслями, не осуждая никого.
Некоторые люди живут в странах, которые сопротивляются изменениям и подвержены полной цензуре (поэтому они могут нормализовать вещи, которые напрямую атакуют свободу с разных точек зрения или культур).
Но Discourse стремится стать ведущей платформой для форумов во всём мире, и я считаю, что обсуждение таких тем всегда полезно для всех.
Спасибо за предоставленное пространство. Надеюсь, что это будет пересмотрено, чтобы не навредить сценариям использования, но и не подорвать доверие пользователей и сообществ к Discourse
Мы говорим о предотвращении потенциально серьёзных злоупотреблений в крупных сообществах, а не о подрыве доверия, которое пользователи оказывают платформе Discourse.
Мы не обсуждаем слепо доверять форумам или предотвращать доступ администраторов к данным, поскольку это невозможно в централизованной системе, использующей единую базу данных.
Я считаю, что этот вопрос лучше всего подходит для формата «Да, но…», а не для спора «Да или Нет».
Извините, но это не суть моей темы. Вы можете открыть отдельную тему и задать любой вопрос, какой пожелаете.
Удаление функции impersonate не предотвращает этого — всё так же легко сделать и без неё. Основным последствием удаления impersonate будет усложнение диагностики проблем, связанных с конкретными учётными записями.
Нет, не упускаю. Ручное управление базой данных — это совершенно не то же самое, что просто нажать и опубликовать, как делает другой участник.
Это включено по умолчанию в стандартном экземпляре Discourse без чётких заявлений или универсальных сценариев использования, кроме тестирования разработчиками.
В этом и суть моей темы. И ещё раз извините, но вы можете открыть новую тему или думать что угодно.
Вам стоит запустить демо-версию и попробовать некоторые функции администратора. Для изменения чьих-либо слов или чтения их сообщений вам не нужен доступ к базе данных или возможность действовать от имени других пользователей.
Один клик или десяток — особой разницы нет, всё равно это возможно. Я знаю человека, который часто работает из дома и должен пройти через около полдюжины паролей, двухфакторную аутентификацию и другие сложности, чтобы попасть во внутренние системы своей компании, но у него на это уходит всего несколько минут.
Либо вы и ваши пользователи доверяете разработчикам и администраторам, либо нет. И если вы не доверяете системе, то, скорее всего, изменится и то, как вы её используете.
Прежде чем отвечать, вам стоит перечитать мои последние несколько постов. Администраторы могут выполнять все эти действия без доступа к имитации или базе данных. Имитация и большинство действий администратора уже логируются на случай, если другому администратору потребуется отслеживать злонамеренные действия.
Или просто отключите эту открытую функцию с помощью плагина Encrypt. В конечном итоге наличие опций для функций, которые могут показаться проблемными, — это хорошо. Ложное чувство безопасности, защищённости и т. д. Единственная по-настоящему безопасная система, по словам Адамы, — это автономный терминал, не подключённый к другим системам.
У всех сторон есть свои аргументы «за» и «против», и у каждого есть своя точка зрения. Компромисс — лучшее решение для всех сторон. Плагин Encrypt, полагаю, был разработан, чтобы удовлетворить желание и в некоторых случаях даже требование наличия уровня конфиденциальности для подсистемы личных сообщений (PM/DM).
Возможно, если не включать эту функцию в ядро как опцию, то хотя бы создать плагин, который реализует желаемый эффект для тех, кто, например, использует самохостинг и хочет иметь спокойствие.
Можно сказать, что скрипт для создания пользовательских значков не нужно отключать, так как только администратор имеет прямой доступ к их созданию. Однако это должно быть включено через root-доступ, если только это не изменилось.
Я согласен: в идеальных условиях люди должны иметь возможность доверять лицам, занимающим определённые должности. К сожалению, доверие иногда оказывается misplaced и обнаруживается только после того, как что-то пошло не так.
Это мера производительности, чтобы убедиться, что размещённые клиенты в общей среде не смогут вывести сайты друг друга из строя. Это позволяет различать администратора сервера и администратора форума.
Один клик или дюжина могут казаться похожими, но это не одно и то же. Именно поэтому многие корпорации теряют огромные суммы, не предоставляя простую кнопку «Отписаться».
Вероятно, мы говорим об обратном, но с точки зрения морали и этики.
Я использую Discourse в качестве администратора уже четыре года и прекрасно понимаю, о чём вы говорите (это совершенно другие случаи, чем имперсонация пользователей).
Вы заявили, что нельзя опубликовать сообщение от имени другого пользователя одним кликом. Это похоже на использование чужого IP-адреса или идентификатора и отличается от редактирования постов в целях модерации.
Кстати, я надеюсь, что шифрование прекратится и появится возможность читать личные сообщения пользователей, но это тема для отдельной ветки, и я жду обновлений для тестирования
Я ещё раз процитирую это, так как похоже, что вы включили режим медленного ответа…
Я размышлял о том, чтобы привести несколько практических примеров «смены владельца» и/или «редактирования вашего сообщения со скрытием истории изменений», чтобы показать, что этот спор в основном беспредметен, так как можно создать впечатление, будто вы сказали что-то, чего не говорили, даже не нажимая кнопку «имперсонация». Но я решил этого не делать.
Однако у меня наверняка есть множество способов вести себя как настоящий негодяй, используя все волшебные кнопки, доступные мне в интерфейсе, не говоря уже о работе с консолью Rails. Я считаю, что многое зависит от доверия сообщества, а не только от администратора, поскольку многие из этих функций доступны на уровнях TL4, модератора категорий и модераторов. В целом, группа «персонал» обычно не стремится использовать инструменты во вред, так как это было бы актом саботажа против собственного сообщества.
Поэтому я не понимаю, почему именно функция имперсонации выделяется как неэтичная?
Серьёзно, все эти комментарии о злоупотреблениях и прочем не имеют для меня смысла. Нет никакого смысла отключать эту конкретную функцию. Администратор всё равно может делать всё, как уже указали другие.
Но вы всё равно не хотите слушать других и хотите раздувать проблему из ничего. Я до сих пор не понимаю, в чём настоящая проблема. Вы потеряете своих пользователей? Или боитесь, что другой администратор воспользуется этой функцией против вас? Если так, то просто не назначайте администраторами тех, кому не доверяете — и всё.
Ричард, я буду полностью откровенен: у вас и у @merefield есть очень веские сценарии положительного использования. Однако мне кажется, что вы оба видите только то, как изменение элементов с опциональными настройками может помешать вашим рабочим процессам. На самом деле это не так, ведь если вы предоставляете хостинг, эта функция для вас обоих не изменится.
Возьмем, к примеру, ситуацию, когда я публикую проблему, с которой мне нужна помощь, и обсуждаю условия оплаты или бесплатной помощи. Вы, Роберт или любой другой, кто предлагает помощь, можете перечислить необходимые инструменты для самостоятельного размещения Discourse.
Например: «Дэн, я могу помочь вам за $X решить вашу проблему. Для этого мне потребуется следующее: создать учётную запись на вашем сайте и получить права администратора. Также мне понадобится доступ к функции «Имитация пользователя» (с перечнем пользователей, на которых разрешено её использование), чтобы я мог правильно и эффективно диагностировать и устранить проблему. Если функция «Имитация пользователя» отключена, вам нужно попросить вашего супер-администратора включить её. Если вы согласны с моими условиями, мы можем начать этот процесс».
Я бы автоматизировал это, так что меня это совершенно не беспокоит (на самом деле у меня есть shell-скрипт, который принимает в качестве аргументов имя хоста и имя пользователя установки Discourse, размещённой нами, и выдает мне ссылку для входа (включая двухфакторную аутентификацию и вход).
Я уже изложил свои возражения более двух часов назад (но с радостью повторю их, чтобы избежать дальнейшей путаницы в отношении моих мотивов).
Вот моя лучшая попытка вручную с помощью GPT-4 обобщить то, что я читаю:
Одни хотят повысить сложность процесса имперсонации.
Другие хотят оставить текущий низкий уровень сложности.
Для тех, кто хочет немного усложнить процесс (я в этой группе, потому что лично не хочу испытывать соблазн нажать кнопку, подобно функциям «Экранное время» и другим трюкам в iOS, помогающим избежать искушения):
Добавьте очень простой компонент темы на ваш сайт со следующим CSS:
.btn-impersonate {
display: none;
}
Возможно, вам нужно ещё больше усложнить процесс, и кто-то может создать плагин или более продвинутый компонент темы для этого, но я хочу попробовать этот вариант и посмотреть, обеспечит ли он достаточное препятствие, чтобы избежать любого нежелательного соблазна.
Для меня это главный момент. Администраторы всё ещё могут «выдавать себя за пользователей» с помощью других доступных инструментов, буквально в несколько кликов.
Но в конечном счёте Discourse — это проект с открытым исходным кодом с системой плагинов, и вы всегда можете настроить всё так, как считаете правильным для своего сообщества.
Если вы хотите плагин, я бы начал с переопределения Guardian.can_impersonate?, который используется сериализатором для определения наличия кнопки «Выдать себя за пользователя», а также для проверок на стороне сервера. По крайней мере, после быстрого теста на моём локальном окружении это сработало:
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
