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

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

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

  • Настроек сайта типа group_list
  • Разрешений категорий
  • Групп тегов

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

Дополнительную путаницу вносит тот факт, что группа @everyone может применяться к настройкам сайта, где предоставление доступа «всем анонимным и авторизованным пользователям» не имеет смысла, например, для pm_tags_allowed_for_groups.

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

Решение

Мы внедряем две отдельные автоматические псевдогруппы:

  • anonymous_users (ID 4) — представляет анонимных пользователей, посещающих ваш сайт без аккаунта
  • logged_in_users (ID 5) — представляет всех авторизованных пользователей вашего сайта, по эффекту аналогично автоматической группе trust_level_0, но более специфично

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

При включении этого будущего изменения любая настройка, где в качестве выбранной группы указан everyone, будет автоматически переведена на ID группы logged_in_users, поэтому данные в таблице настроек сайта не изменятся при переключении будущего изменения. Когда это изменение станет постоянным, мы выполним миграцию данных для всех настроек групп, чтобы внести это изменение.

Кроме того, группа anonymous_users помечена как disallowed_group для нескольких настроек сайта, где её использование не имеет смысла, например, personal_message_enabled_groups.

image
image1217×205 51.6 KB

Конфликты с существующими именами групп обрабатываются автоматически: существующие группы переименовываются, а упоминания групп в постах обновляются.

А что насчёт разрешений для тегов и категорий?

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

8 лайков
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

Подождите… что? :flushed_face: Это значит, что все категории, которые сейчас открыты для всех (everyone), станут закрытыми и потребуют входа в систему, когда эта функция будет включена?

4

Нет, потому что:

Это касается только настроек сайта типа «список групп», которые в настоящее время позволяют выбирать «всех» следующим образом:

image
image909×273 54 KB

1 лайк
5

Может, кто-нибудь поможет мне понять, как мне нужно адаптировать компоненты моей темы?

Я попробовал использовать компонент copy-post в качестве примера, так как помню, что он тоже использует настройку группы, предоставляющую доступ к функции. И что была проблема, потому что псевдогруппа «все» требовала отдельной проверки, точно так же, как в моём компоненте, поскольку сравнение идентификаторов групп, к которым принадлежит пользователь, не помогает — эти идентификаторы нужно проверять отдельно. Поэтому я ожидал недавних изменений там, так как, насколько я понимаю, новые группы тоже являются псевдогруппами, и идентификатор нужно проверять отдельно. Не упускаю ли я что-то, что объясняет, почему здесь это не требуется?

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

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

Не является ли всё, о чём я беспокоюсь, на самом деле ненужным? Если нужны какие-то изменения, то менее четырёх недель — довольно короткий срок, учитывая количество поддерживаемых сообществом компонентов, которые могут быть затронуты.
Помимо «copy-post» я также посмотрел на компонент фильтра неотвеченных тем, но не нашёл там никаких изменений. Ощущение, что я упускаю что-то важное. В конце концов, изменение уже включено по умолчанию почти неделю. Поэтому я предполагаю, что официальные компоненты уже были бы обновлены, если бы потребовались какие-либо корректировки.

1 лайк
6

3 сообщения были объединены в существующую тему: Модернизация темы Foundation

7

Судя по этим компонентам, currentUser?.groups в любом случае ненадёжен, поскольку он включает только видимые группы пользователя, а группы, влияющие на разрешения, могут не быть сериализованы здесь:

В ядре и плагинах мы обходим это, делая что-то подобное в сериализаторе текущего пользователя:

Но, очевидно, это недоступно для тематических компонентов/тем и их настроек.

Хм, не уверен, нужно будет подумать об этом. Если вы действительно имели в виду everyone, то это должно измениться на logged_in_users И anonymous_users. Это была основная проблема с everyone, как указано в исходном посте — некоторые люди понимали это как только зарегистрированных пользователей, другие — как зарегистрированных плюс анонимов, и это сильно зависело от ситуации.

Я выбрал интерпретацию «только зарегистрированные пользователи», потому что это безопаснее с точки зрения безопасности.

Нет, просто я не подумал о тематических компонентах/темах и их настройках и о том, как это изменение на них повлияет. Я был сосредоточен в основном на настройках сайта. Такие вещи особенно трудно найти, поскольку они даже не используют константу AUTO_GROUPS:

image

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

2 лайка
9

Краткое обновление: у меня есть идея, как это решить, и мы сейчас обсуждаем это внутри команды. Надеюсь, это займёт не слишком много времени :crossed_fingers:

1 лайк