# Управление членством в группе через аутентификацию

**URL:** <https://meta.discourse.org/t/managing-group-membership-via-authentication/175950>\
**Category:** Development\
**Created:** [13.Январь.2021 06:50:24 UTC](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950 "2021-01-13T06:50:24Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)\
**Post date:** [19.Март.2021 15:31:16 UTC](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950/13 "2021-03-19T15:31:16Z")

</div>

Это выглядит очень круто!

> [@angus](#):
>
> Мне также пришлось ввести новую концепцию «вторичной авторизации» в момент аутентификации.

Я **немного** сомневаюсь насчёт идеи «вторичной авторизации», а также столбца `provider_domain`. Не могли бы вы подробнее объяснить, зачем они нужны? Кажется, что они довольно специфичны для Google… Есть ли причина, по которой мы не можем запросить область видимости `admin.directory.group.readonly` уже при первом запросе аутентификации? И, возможно, просто добавить префикс с доменом к названию группы? (Или вовсе исключить домен, поскольку я предполагаю, что люди будут использовать это только с одним «хостинг-доменом» Google?)

> [@angus](#):
>
> Вы также заметите, что я добавил три новые таблицы. Я пытался реализовать несколько более «лёгких» решений, но каждое из них в итоге оказывалось более запутанным и неэффективным при обработке обновлений связанных с пользователем групп и связанных с группой групп.

Да, я полностью согласен с тремя таблицами здесь — это делает структуру чище.

> [@angus](#):
>
> - Возможно, сериализовать `label` в `associated_groups` (вместо моделирования на стороне клиента).

Согласен 👍

> [@angus](#):
>
> - Возможно, перенести создание/удаление записей `user_associated_group` и `group_associated_group` в фоновую задачу, так как при большом количестве это может работать медленно.

Здесь нужно быть осторожными. Любые членства в группах должны быть назначены **до** того, как пользователь впервые загрузит сайт. Иначе они не увидят специфичные для группы элементы при первом входе (например, защищённые категории). Поэтому я считаю, что изменения в записях `user_associated_group` должны обрабатываться синхронно.

Однако для изменений записей `group_associated_group`, думаю, вы правы. Такие изменения могут затронуть тысячи пользователей, поэтому их нужно будет обрабатывать [in\_batches](https://www.rubydoc.info/github/rails/rails/ActiveRecord%2FBatches:in_batches). Я бы начал с синхронной обработки, добавив в интерфейсе индикатор загрузки. Так администраторы будут чётко видеть, когда процесс запущен и когда завершён.

Если время обработки приблизится к 30 секундам (тайм-аут запроса в unicorn), тогда, возможно, потребуется подумать о фоновой задаче.

Также, возможно, стоит подумать о добавлении блокировки DistributedMutex. Например, что произойдёт, если пользователь войдёт в систему **во время** обработки изменения `group_associated_group`? Готов обсудить подобные вопросы на GitHub, как только мы окончательно утвердим общую архитектуру.

---

_[View the full topic](https://meta.discourse.org/t/managing-group-membership-via-authentication/175950)._