Отключение "enable names" заставляет администратора вести себя странно

Внести вклад Ошибка
29

Я уже изложил контекст сценария использования по адресу Restrict exposure of full name to certain groups. Мы используем Discourse для организации обсуждений о местном общественном образовании; наша целевая аудитория — в основном родители и другие члены местного сообщества. Мы хотим найти баланс:

  • С одной стороны, сделать сайт открытым для анонимного просмотра (чтобы поисковые системы могли его индексировать, чтобы он был доступен даже не-участникам, чтобы он был открытым и прозрачным в принципе и т. д.).
  • С другой стороны, избежать ненужного предоставления лично идентифицируемой информации краулерам и случайным посетителям, не являющимся участниками. Мы хотим дать людям возможность делиться своими именами внутри сообщества и хотим решить проблему осторожности, с которой многие подходят к этому.

Изначально казалось, что отключение опции «Отображать имя в сообщениях» и включение опции «Скрыть профили пользователей от публичного доступа» решит проблему утечки имен анонимным пользователям. Однако мы поняли, что это не так. (А мы уже обещали людям через Условия использования и FAQ, что сделаем это. :lying_face:)

Отказ в доступе к полным именам только для анонимных пользователей решил бы задачу. Но поскольку привязка доступа к членству в группе не сложнее, я подумал: «почему бы и нет?» — это также открывает возможность на нашем сайте ограничить доступ пользователям с уровнем TL1 и выше, что ещё лучше. (В настоящее время для регистрации требуется приглашение, но мы хотим от этого отказаться.)

Изучая эту проблему/тему, я встречал другие упоминания о схожих запросах, например: «мы хотим, чтобы имена видели только участники такой-то группы»… так что это решение подойдёт и для таких случаев.

Вопрос к вам (который вы даже можете считать вопросом о продукте):

  • Предназначена ли настройка enable_names для того, чтобы означать «Не показывать полные имена пользователям», или же «Этот сайт вообще не использует полные имена»?

У меня сложилось ощущение (исходя из самого кода и таких тем/проблем, как эта), что в этом вопросе существует фундаментальная неясность — некоторые люди понимают его одним образом, а другие — другим.

4 лайка
30

Есть ли какие-то новости по этому вопросу? Похоже, это самое простое решение с наибольшим положительным эффектом.

4 лайка
31

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

3 лайка
32

Буду очень признателен за прогресс в этой теме. У нас есть насущная и постоянная потребность в этом.

1 лайк
33

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

Отключение опции «enable names» в настоящее время нарушает ключевую функциональность администратора, что, похоже, не было задумано. Отсутствие ясности относительно того, является ли это намеренным решением или ошибкой, затрудняет наше планирование. Для тех из нас, кто управляет рабочими сайтами, где предпочтительны имена пользователей вместо полных имен, это ограничение создает реальные неудобства и непредвиденное поведение.

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

1 лайк
34

Привет, @tobiaseigen, есть ли какие-либо комментарии от инженеров по этому поводу? (Прошло уже 3 месяца, но я тоже был занят другими делами и потерял нить обсуждения, так что не могу жаловаться.)

Я мог бы начать отправлять pull request(ы) на этой неделе, чтобы сделать разговор более конкретным, но я опасаюсь, что они останутся без ревью. Кроме того, мне была бы полезна обратная связь по некоторым аспектам моего подхода.

Редактирование: Для ясности, я говорю о pull request’ах для реализации Restrict exposure of full name to certain groups - #2 by mdoggydog (которая позволяет включить enable names, контролируя при этом, кто может видеть полные имена).

2 лайка
35

@RGJ @chrismalone и @mdoggydog Огромное спасибо за ваш вклад. Нам по-прежнему нужен этот исправление, и мы благодарны всем, кто работает над этой проблемой.

2 лайка
36

Честно говоря, я удивлён, что на это не обратили больше внимания. Я понимаю, что люди могут опасаться делать pull request, не зная, будет ли он рассмотрен и, возможно, внедрён.

Хотя, думаю, pull request мог бы стать плагином, но это ещё больше ограничивает этот вариант только для саморазмещённых решений.

39

@mdoggydog Похоже, ваше решение здесь заключается в том, чтобы заменить настройку «enable names» на настройку, принимающую список групп, при этом имена участников будут видны только этим группам.

Обратите внимание, что это всё ещё должно учитывать настройку «display name on posts» (и любые другие подобные настройки, которые могут существовать), поэтому даже разрешённые группы не увидят имя в публикациях, если эта настройка отключена.

Кроме того, нам также нужно исправить/изменить некоторые другие вещи как побочные эффекты:

  1. Имена всегда должны быть видны в административном просмотре профиля пользователя. Это будет работать независимо от любых настроек.
  2. Имена должны отображаться в письмах только если пользователь входит в разрешённую группу.

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

Звучит ли это так, как вы предлагаете? Если да, мы с удовольствием рассмотрим любой PR, который вы отправите с этим обновлением.

40

Написанный мной код не удаляет настройку enable names[1], а дополняет её:

  1. Добавить настройку full_names_visible_to_groups (которая включает admins и moderators как обязательные значения).
  2. Добавить метод can_see_full_names? в Guardian, который выполняет логическое «И» между enable_names и членством в группах из full_names_visible_to_groups.
  3. Использовать этот новый метод во всех подходящих местах, где полное имя раскрывается/отправляется сервером.

Пункты 1 и 2 были простыми. Пункт 3 сложнее, и я знаю, что столкнулся с некоторыми проблемами, которые не мог решить без консультации/руководства. Мне нужно вернуться и детально пересмотреть свой код и заметки. (Прошло уже более 2 месяцев с тех пор, как я в последний раз погружался в эту тему. :see_no_evil_monkey:)

(Если я не ошибаюсь, display name on posts и подобные настройки являются клиентскими, влияющими на представление данных, полученных от сервера. Иными словами, это ограничение поверх того, что отправляет сервер.)

Я считаю, что пункт (1) решён, если enable_names равен true, что, вероятно, захотят почти все, как только станет доступна новая настройка для каждой группы.[2]

Думаю, я столкнулся с пунктом (2) и решил его — в основном.[3]

Вспоминаю ещё несколько случаев, когда полные имена утекают.[4]

В любом случае, я пересмотрю свои заметки и попробую отправить PR на этой неделе, а заодно подниму открытые вопросы и нерешённые проблемы в процессе.

  1. …по ряду причин, среди которых: (а) я не был уверен в истинном назначении этой настройки (см. мой вопрос в предыдущем посте выше), и (б) её сохранение обеспечивает более безопасный путь постепенного обновления. ↩︎

  2. …если исходить из того, что enable_names = false означает «Этот сайт не использует полные имена ни в каком виде.» ↩︎

  3. Например, когда приглашение отправляется на какой-то адрес (очевидно, не связанный с пользователем, иначе приглашение не понадобилось бы), включает ли письмо полное имя приглашающего или нет? ↩︎

  4. Например, в oneboxer.rb, при oneboxing локального пользователя, полное имя записывается в обработанное содержимое поста, что делает его видимым для всех и каждого навсегда. ↩︎

4 лайка
How to hide just names and usernames for anonymous users
41

Звучит отлично! Можете оставить ссылку на ваш PR здесь? Тогда я попрошу инженера внимательно его рассмотреть.

6 лайков
42

Первый (из 2 или 3) PR уже здесь:

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

Мое мини-приключение с аккаунтом на GitHub

…ну, он был там, пока я не ввёл URL в поле редактирования здесь… и тогда мой аккаунт внезапно был заблокирован. :face_with_monocle: :weary_cat: :face_with_symbols_on_mouth: :crying_cat_face: :alien:

Я подал запрос на восстановление и обновлю эту запись, как только получу новости.

Через 13 часов я получил письмо, в котором по сути говорилось: «Иногда такое случается; всё в порядке». Очень кафкиански. Мой аккаунт исчез с сайта — настолько, что посты, которые я делал в Issues/PRs годами, пропали, оставив после себя загадочные односторонние диалоги, где единственным свидетельством присутствия другого человека (меня) оставались несколько призрачных цитат.

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

3 лайка
43

Я понимаю, что это потребует координации изменений также в репозиториях плагинов Discourse — что означает цепочку PR в порядке, условно говоря, «изнутри наружу», чтобы гарантировать, что тесты всегда проходят (и, конечно, что main всегда работоспособен).

Предполагаемая последовательность действий выглядит так (где CORE означает «PR в discourse/discourse», а PLUG — «PR(ы) в официальных репозиториях плагинов»):

  1. Принудительная пересылка области видимости сериализатора (ожидаемых функциональных изменений нет)
    a. CORE: Реализовать проверку области видимости сериализатора, отключена по умолчанию
    b. PLUG: Исправления для пересылки области видимости
    c. CORE: Исправления для пересылки области видимости и включение проверки области видимости по умолчанию
  2. Заблаговременное предоставление объектов Guardians (вместо заглушек) в необходимых местах для этапа 4 (ожидаемых функциональных изменений нет)
    • CORE: Исправления заглушек
    • PLUG: Исправления заглушек
  3. Реализация простого метода Guardian#can_see_full_names?, зависящего только от enable_names (ожидаемых функциональных изменений нет)
    • CORE: Добавить метод в Guardian
  4. Использование can_see_full_names? везде, где выводятся полные имена (заменяя прямое использование enable_names там, где это уместно) (возможны функциональные изменения)
    • CORE: Использовать новый метод Guardian
    • PLUG: Использовать новый метод Guardian
  5. Реализация настройки full_names_visible_to_groups (функциональное изменение)
    • CORE: Добавить новую настройку в конфигурацию и проверять её в методе Guardian

Пункты (1) и (2) сводятся к обеспечению более последовательного и надежного использования Guardians во всей кодовой базе Discourse.

Пункты (3) и (4) направлены на внедрение более точной абстракции для контроля того, когда полные имена раскрываются бэкендом (решение о раскрытии принимается в зависимости от контекста, который представляет Guardian).

Пункт (5) — это, наконец, (относительно тривиальная) часть, где раскрытие полных имен ограничивается членством в группах.

3 лайка
45

Спасибо! Я подключил инженера, чтобы он посмотрел. Похоже, вы на верном пути, но инженер сможет дать более обоснованную обратную связь :slight_smile:

4 лайка
48

@hugh спасибо, что довели этот вопрос до нужных людей для его продвижения. Мы надеемся на это уже какое-то время.

1 лайк
49

Извините, но я вынужден отклонить этот PR. Это изменение слишком сложное и трудное в поддержке. Основные причины:

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

Отображение имени пользователя или полного имени в зависимости от группы — довольно сложная задача. Вместо того чтобы пытаться внедрить это в ядро Discourse, можем ли мы начать с создания плагина? Если ваше сообщество небольшое, это может работать так:

  • Установите SiteSetting.enable_names в false, чтобы всегда использовать имя пользователя;
  • Определите эндпоинт, который будет возвращать карту «имя пользователя → полное имя» для пользователей уровня TL3;
  • Используйте вызов API formatUsername для добавления полного имени или его замены для пользователей уровня TL3 — https://github.com/discourse/discourse/blob/main/app/assets/javascripts/discourse/app/lib/plugin-api.gjs#L1711
2 лайка
50

Я только что завершил PR, решающий исходную проблему. Администратор всегда сможет видеть полное имя и редактировать его. Мы постараемся объединить его на следующей неделе на раннем этапе :crossed_fingers:

3 лайка
51

Кажется, всё ещё существует фундаментальное непонимание или разногласие относительно того, что именно должна делать настройка enable_names, что сводится к следующему вопросу:

  • Предназначена ли настройка enable_names для того, чтобы:
    1. «Не показывать полные имена публично»,
    2. «Этот сайт не использует полные имена вообще»?

Мне кажется, что некоторые участники этой темы полагают, что она выполняет (1), а другие — что (2). Моё впечатление таково: последнее, то есть enable_names определяет, использует ли сайт полные имена вообще.

Имейте в виду: когда enable_names отключено:

  • В диалоге регистрации не предлагается поле для полного имени.
  • Пользователи не видят поле полного имени на своей странице настроек аккаунта; пользователи никогда не видят своё собственное полное имя нигде.

Я не понимаю, какой может быть сценарий использования сайта, где только администраторы знают о существовании поля полного имени в системе. Моё воображение не позволяет мне поверить, что кто-то здесь действительно этого хочет. Если кто-то всё же этого хочет, пожалуйста, просветите меня!

(Кажется, также существует некоторое непонимание того, к чему, как и зачем стремится мой черновик PR, но сначала я хотел бы ответить на вопрос «Что на самом деле делает enable_names?».)

2 лайка
Full name requirement for signup not showing up in form if enable names is disabled
52

Да, я могу назвать множество примеров. Часто компания, владеющая сообществом, имеет законное право (и/или необходимость) знать имена своих клиентов, но законы о защите персональных данных запрещают им публиковать эти имена третьим лицам. Это практически то же самое, что и запрет на использование поля «Копия» (CC) в массовой рассылке; вместо этого следует использовать «Скрытую копию» (BCC).

Ну, изначально это было довольно простым отчётом об ошибке, где параметр просто работал некорректно. Затем мы все погрузились в обсуждение того, что он должен делать, что также вызвало много путаницы и дополнительных дискуссий. Это нормально, но такое обсуждение лучше было бы провести в теме #feature.

Это вариант №1. Описание параметра гласит:

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

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

Также существуют параметры display_name_on_posts, full_name_requirement и display_name_on_email_from.

Если вы хотите вариант №2, то, думаю, было бы логичнее доработать параметр full_name_requirement и добавить там опцию «Никогда».

(И да, я согласен, что enable_names следовало бы назвать иначе, но переименовывать параметры — это никогда не весело). Также я согласен с тем, что

— это странно.

1 лайк
53

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

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

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

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