# Детальные групповые права доступа для анонимных и авторизованных пользователей
**URL:** https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273
**Category:** Announcements
**Tags:** groups
**Created:** [13.Май.2026 01:18:57 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273 "2026-05-13T01:18:57Z")
**Posts on this page:** 1
**Showing post:** 11
### Author:  [@martin](https://meta.discourse.org/u/martin)
#### Post date: [06.Июль.2026 01:59:03 UTC](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273/11 "2026-07-06T01:59:03Z")
> [@Noble\_Fish](#):
>
> Интересно, существует ли таблица, разъясняющая значение этого термина в разных контекстах. Такие различия вводят в заблуждение и вызывают беспокойство — ведь когда люди изначально выбирали эту настройку, они, вероятно, не знали её реального значения, поэтому захотели бы проверить связанные параметры. Сейчас я могу только проверять каждое место, где настраиваются группы, по отдельности, и выяснять, что означало это значение раньше, глядя, на что оно изменилось после включения функции «Детальные группы» — это всё равно что шарить в темноте.
Отличная идея… Возможно, я смогу с помощью ИИ проанализировать все места, где используются настройки на основе групп, и выяснить, возможно ли вообще для `anonymous` получить доступ к этим ресурсам.
Есть целый ряд настроек, которые уже запрещают выбор группы `anonymous_users`, так что это, вероятно, хорошее отправное место… скоро отпишусь здесь с результатами.
> [@martin](#):
>
> Краткое обновление: у меня есть идея, как это обработать, и мы сейчас обсуждаем это внутри команды. Надеюсь, это не займёт слишком много времени 🤞
Сейчас я работаю над PR для этого:
>
>
> Currently, theme settings with \`type: list\` and \`list\_type: group\`
> require clie…nt-side permission checks, but \`currentUser.groups\` only
> includes visible groups, not all groups the user belongs to. This makes
> permission checks unreliable and can leak hidden group membership.
>
> To address this, this commit adds an opt-in \`resolve\_group\_membership:
> true\` option that replaces the group ID list with a user\_in\_SETTING\_NAME
> boolean resolved server-side via \`guardian.in\_any\_groups?\`. The original
> group list is removed from the frontend payload to prevent leaking group
> IDs.
>
> Since theme settings are cached per-theme (not per-user), the resolution
> happens after the cache lookup during per-request serialization in
> \`ApplicationLayoutPreloader#activated\_themes\_json\`.
>
> Example YAML:
>
> \`\`\`yaml
> copy\_button\_allowed\_groups:
> type: list
> list\_type: group
> resolve\_group\_membership: true
> default: "1|3"
> \`\`\`
>
> Frontend usage:
>
> \`\`\`javascript
> if (!settings.user\_in\_copy\_button\_allowed\_groups) return;
> \`\`\`
Скоро после этого будут следующие PR и изменения в документации.
---
_[View the full topic](https://meta.discourse.org/t/granular-group-based-permissions-for-anonymous-and-logged-in-users/402273)._