Детальные групповые права доступа для анонимных и авторизованных пользователей

Новости и события Объявления
23

Никаких проблем! Рад, что disallowed_groups окажется полезной. Я только что объединил этот PR.

Теперь, когда у нас есть disallowed_groups и resolve_group_memberships, мне нужно пройти по всем нашим официальным темам и компонентам. Предлагаю вам и @moin сделать то же самое для ваших собственных тем и компонентов, как только будет возможность, поскольку после внесения изменений в наши официальные репозитории я очень хочу двигаться дальше и перевести изменения, описанные в исходном сообщении, в статус stable.

Многие другие основные функции теперь зависят от anonymous_users и logged_in_users или используют их, и я очень хочу удалить группу everyone.

3 лайка
24

Привет, Мартин, вопрос:

Я только что выполнил полное обновление моего экземпляра и теперь добавляю параметр объекта disallowed_groups в свой компонент для групп everyone и anonymous_users, используя идентификаторы автоматических групп, указанные здесь:

Вот так:

      groups:
        type: groups
        disallowed_groups: "0|4"
        required: true
        resolve_group_membership: true
        validations:
          max: 20

Но в выпадающем списке групп компонента по-прежнему отображается группа everyone:

Screenshot 2026-07-19 at 5.21.44 PM
Screenshot 2026-07-19 at 5.21.44 PM890×1010 38.6 KB

Что я делаю не так с параметром объекта? Я заметил, что даже без указания disallowed_groups в объектах группа anonymous_users по-прежнему не отображается (так что в данный момент список в моем компоненте выглядит одинаково, независимо от того, задаю я disallowed_groups или нет). Я протестировал с другими идентификаторами групп, и, похоже, я неправильно использую disallowed_groups (или синтаксис), так как он, кажется, не оказывает никакого эффекта, независимо от того, какие идентификаторы я использую.

4 лайка
25

Сегодня утром были некоторые проблемы с GitHub, поэтому изменения в disallowed_groups только сейчас попали в последнюю версию Commits · discourse/discourse · GitHub

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

1 лайк
26

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

Screenshot_20260720_081640_Firefox
Screenshot_20260720_081640_Firefox691×1038 99.8 KB

Я также обновил форум, и группы everyone и anonymous_users скрыты, как и ожидалось.

Для ясности: это я отключил изменение примерно две недели назад :innocent:

3 лайка
27

хаха :smiley: спасибо, Moin! я на самом деле забыл, что новая настройка гранулярных групп и так была в предстоящих изменениях.

Мартин, настройка объекта disallowed_groups работает идеально. мне очень нравится это изменение. ещё раз спасибо команде — отличное улучшение. :discourse: :chefs_kiss:

6 лайков
28

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

29

По умолчанию мы не добавляем эти CSS-классы к тегу body. Вы имеете в виду CSS Classes for Current User's Groups ?

Этот компонент необходимо обновить, чтобы добавлять group-anonymous или group-logged-in-users в зависимости от того, авторизован ли текущий пользователь.

2 лайка
30

Привет, Мартин :wave:

Я создал быстрый PR, чтобы добавить эти два класса (anonymous_users и logged_in_users).

Я особо не тестировал (лол), но, думаю, всё довольно просто. Код просто проверяет, существует ли текущий пользователь, и если да, то он является членом logged_in_users, а если нет, то anonymous_users. :grin:

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

2 лайка
31

О, да, ты права, я раньше этого не замечал, я смотрел только на <body> :

Я всё равно одобрил твой PR для компонента, думаю, это нормально :slight_smile:

2 лайка
33

Кроме того, сообщаю всем, что я еще не публиковал здесь, но я объединил эти PR для официальных компонентов, чтобы использовать resolve_group_membership и disallowed_groups:

Сейчас я работаю над планом дальнейших шагов для этого предстоящего изменения. Думаю, что в некоторых местах основного/плагинового кода все еще напрямую обращаются к everyone или не используют user.in_any_groups? на стороне сервера.

2 лайка
34

Есть ли причина, по которой это ещё не было слито?

Причина, по которой я создал эту тему, в том, что я наконец обновил свой компонент.

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

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

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

35

Нет, по какой-то причине, кажется, мой мозг решил, что это не PR в организации Discourse :man_facepalming: Объединю сразу после завершения проверок CI.

Для таких случаев и других в будущем, думаю, лучшим решением, вероятно, будет написание миграции для каждой темы/компонента отдельно Migrate Discourse theme settings

36

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

37

Приношу извинения, если это уже упоминалось, а я пропустил…

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

aabbccdd_allowed_groups:
  refresh: true
  default: "1|2"
  type: list
  list_type: group
  resolve_group_membership: true

console.log(settings.aabbccdd_allowed_groups); // undefined

console.log(settings.user_in_aabbccdd_allowed_groups); // true или false

Это сделано намеренно?

1 лайк
38

Думаю, так и есть. В противном случае решение этой ошибки могло бы быть другим.

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

2 лайка
39

Спасибо, Moin, это абсолютно верно. @gormus единственное место, где по-прежнему передаются реальные идентификаторы групп, — это административный интерфейс для настроек темы.

Не уверен, что это было понятно из моих предыдущих сообщений, но anonymous_users и logged_in_users можно использовать в любое время без включения этого предстоящего изменения; я добавил их независимо несколько месяцев назад. Вот что делает предстоящее изменение:

Таким образом, в любом случае вы в безопасности, если вы удалите everyone везде, где он используется, и с этого момента будете использовать только anonymous_users и logged_in_users.

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

3 лайка
40

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

1 лайк
41

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

  1. anonymous_users и logged_in_users вообще отсутствуют в выборе групп. Думаю, сейчас можно разрешить их использование здесь, и тогда не будет иметь значения, добавили вы everyone в disallowed_groups или нет, если предстоящее изменение отключено.
  2. Исправить Guardian::AnonymousUser#in_any_groups?, чтобы он учитывал anonymous_users, когда предстоящее изменение отключено.
  3. Добавить то же самое алиасирование времени чтения 0 (everyone) → 5 (logged_in_users) для настроек тем, которое мы используем для настроек сайта.

Думаю, я также могу пометить everyone как (устаревший) в селекторе(ах) групп, пока предстоящее изменение остаётся опциональным и отключённым.

Придам этим задачам приоритет и добавлю их в мой общий план, над которым я работаю.

The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions
42

Я создал отдельную тему здесь @moin The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions . Исходное сообщение неполное, я всё ещё разбираю все случаи локально и буду регулярно обновлять тему. Мне не мешает, если вы продолжите писать в этой теме, но я бы предпочёл, чтобы дальнейшее обсуждение велось в новой, чтобы я мог цитировать части исходного сообщения или дополнять его по мере необходимости.

2 лайка
43

Подождите, только что это увидел.

То есть, некоторые люди запутались из-за того, что «все» означает только пользователей, вошедших в систему?

Кто?!?

«Все» — это «все», правда? Очень понятно.

«Все» — это ведь все, кто заходит на сайт, независимо от того, вошли они в систему или нет, верно? Разве это не просто?

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

А если нет, и нужно указывать только «анонимы», потому что это синоним «всех» — то это больше некорректно, так как вошедшие пользователи не являются анонимами.

Единственное, что требовало некоторого «обучения» в Discourse, это то, что TL0 в некоторых случаях означало «все, у кого есть аккаунт и кто вошел в систему», но также могло означать «те, кто еще не достиг TL1, но у кого есть аккаунт и кто вошел в систему».

Ключевой момент здесь в том, что это не представляло собой единую группу людей, а обозначало порог, и это было важно.

Изменив просто TL0 на «вошедшие пользователи», вы теперь нарушаете согласованность каждого уровня безопасности как порога. TL1 также является порогом, а не совсем «единой группой». Значит, нам теперь нужна группа с названием «вошедшие пользователи, которые как минимум на уровне доверия 1»?!?

Я совсем не убежден, что в этом вообще была необходимость — изменения ради изменений?

3 лайка