Как вы, вероятно, догадываетесь, я тоже заинтересован в поиске стабильного решения этой проблемы, которая не специфична для плагина openid-connect. Посмотрим, сможем ли мы найти путь вперёд.
Касательно вашего замечания.
Как вы решаете, в какие группы добавлять пользователя и из каких удалять? И как это влияет на ручное добавление/удаление пользователей из групп в самом Discourse?
Пользователь аутентифицируется через OIDC с группами ['group1', 'group2']
В интерфейсе Discourse пользователя добавляют в group3
Позже тот же пользователь аутентифицируется через OIDC с группами ['group1']
Осматривая это как человек, мы видим, что конечное состояние должно быть group1, group3 (group2 должен быть удалён). Но я не думаю, что отслеживается достаточно состояния, чтобы принять такое решение программно. Аналогично:
Пользователь аутентифицируется через OIDC с группами ['group1', 'group2']
В интерфейсе Discourse пользователя удаляют из group1
Позже тот же пользователь аутентифицируется через OIDC с группами ['group1', 'group2']
Что теперь должно произойти? Администратор явно удалил пользователя из group1, но OIDC просто вернул его обратно. Это очень запутанный UX для администратора. Возможно, нам понадобится способ помечать группы как «управляемые извне» и скрывать весь интерфейс добавления/удаления
Я думаю, есть несколько способов решить эту проблему (они не исключают друг друга)
Идентификация групп и атрибутов токена
В любой реализации явное указание
каких групп членство может управляться через аутентификацию; и
какие атрибуты в токене аутентификации определяют членство в группах
должно быть обязательным, будь то через настройки сайта, настройки групп или иным способом, и по умолчанию должно быть «выключено».
Строгая или гибкая обработка
Обработка считается «строгой», если пользователь удаляется из группы, когда она отсутствует в указанном атрибуте токена. Обработка считается «гибкой», если пользователь не удаляется из группы, когда она отсутствует в указанном атрибуте токена.
Как вы предлагаете, можно отключить добавление/удаление членства в группах через админку групп, если обработка настроена как «строго».
Идентификация источника членства
Также можно хранить источник членства в группе в таблице group_users, чтобы реализовать «смешанный» подход внутри группы, т. е. администратор не сможет удалять членства, созданные через токен аутентификации.
Чем больше я об этом думаю, тем больше склоняюсь к тому, что это должно быть реализовано через настройки групп.
Спасибо @angus за начало обсуждения! Я знаю, что многим эта функция интересна!
Интересно! Я всегда представлял, что группы будут создаваться автоматически в процессе аутентификации, и что имя группы будет полностью соответствовать имени группы у провайдера идентификации. Именно так сейчас работает DiscourseConnect.
Но мне на самом деле очень нравится этот более явный вариант! Это значит, что экземпляры Discourse пользователей не будут засоряться ненужными группами от их провайдера идентификации, и что администраторы смогут настраивать имена групп по своему усмотрению. Это во многом аналогично нашему существующему механизму членства на основе домена электронной почты.
С технической точки зрения это звучит хорошо. Моя единственная опасение заключается в том, что это может быть сложно объяснить пользователям и администраторам. Если мы последуем вашей идее «явного указания» групп, управляемых аутентификацией, я думаю, мы могли бы просто реализовать «строгую» обработку?
Когда группа настроена как управляемая аутентификацией, ручное добавление/удаление скрывается за большим предупреждением, и она ведёт себя как описанный вами «строгий» режим.
Как вам это?
Кстати: нам также следует убедиться, что все автоматические добавления/удаления пользователей фиксируются в журнале группы. Это поможет всем легче понять, что происходит и почему.
Да, я считаю, что для первой версии этого набора функций лучше действовать явно. Я пока не встречал случаев, когда автоматическое создание было бы действительно необходимо, то есть когда группу нельзя было бы просто настроить и сконфигурировать администратором сайта до обработки любых утверждений.
Возможно, мы сможем внедрить автоматическое создание как опцию после реализации явного варианта?
Что касается настроек группы, это могло бы выглядеть следующим образом:
Раздел настроек: Членство (т. е. существующий раздел) Заголовок группы настроек: Управление аутентификацией Настройки:
Сервис: Список служб аутентификации. Опция «Все» также будет доступна. Эта настройка будет также выполнять функцию состояния «включено/выключено» для данного набора функций. Т. е. по умолчанию будет выбрано «Нет».
Утверждение: текстовое поле для ввода утверждения токена идентификатора. «Описание» для этой функции (возможно, в посте здесь, на Meta) объяснит поддерживаемые форматы, например, булево значение, строка, разделенная запятыми и т. д.
Режим: см. ниже
Да, если бы существовала настройка «строгий/нестрогий», нам пришлось бы объяснить её кратко. Я думаю, что подход должен заключаться в фокусировке на «добавлении» и «удалении». Вы могли бы описать это следующим образом:
Настройка: «Режим»
Вариант 1 (нестрогий):
Метка: «Добавлять участников»
Описание: «Разрешить добавление участников в эту группу в процессе аутентификации»
Вариант 2 (строгий):
Метка: «Добавлять и удалять участников»
Описание: «Разрешить как добавление, так и удаление участников в процессе аутентификации. Это отключит ручное управление членством.»
Причина, по которой я стремлюсь сохранить вариант «нестрогий», заключается в том, что при работе с клиентами над подобными задачами ранее это был наиболее распространенный случай использования, т. е.
Основная потребность — предоставить доступ к группе в зависимости от состояния во внешней службе.
Потребность в удалении доступа в зависимости от состояния во внешней службе менее актуальна, т. е. люди действительно теряют доступ и должны быть удалены, но это относительно менее важно.
Часто возникает желание сохранить возможность ручного управления членством в Discourse. Когда я реализовывал «строгий» подход, это вызывало «удивление» (т. е. «Почему пользователь X потерял членство?»), несмотря на объяснения и корректную работу (с технической точки зрения).
Да, это важно, так как пользователи часто будут задаваться вопросом «почему» кто-то был добавлен или удален, особенно в строгом режиме, и мы (т. е. «Discourse») не будем контролировать достоверность утверждений, предоставляемых внешней службой аутентификации.
Возможно, стоит ввести новый тип действия «Удалить пользователя» и «Добавить пользователя», который включает название службы аутентификации, ответственной за действие, например, «Удалить пользователя ([название службы])».
Ещё один «подводный камень» здесь заключается в том, что нам нужно чётко обозначить: это не панацея для сценария «Я хочу, чтобы членство в группе определялось на основе внешней службы X», поскольку пользователи аутентифицируются не так часто, или, по крайней мере, не в том объёме, который требуется для стандартного сценария такого типа.
Это (управление аутентификацией) — необходимая часть обработки подобного сценария, но для его полноценной поддержки также требуется настроить интеграции на основе событий, например, приёмник вебхуков (у нас есть приватный плагин приёмника вебхуков, разработанный для управления группами, который я надеюсь скоро открыть как проект с открытым исходным кодом).
Это очень ценная работа, которую вы здесь выполняете!
Просто для сравнения функциональности, хотел поделиться тем, что мы делаем в Глобальной сети правовой эмансипации. Мы используем WordPress и плагин Discourse для WordPress. У нас настроено так, что при каждом обновлении пользователя в WordPress изменения автоматически отражаются в Discourse. Это касается как специальных групп (например, «основной участник», «вкладчик ресурсов» и т. д.), так и деталей профиля. Мы добавили скрытое поле пользователя «последнее обновление», что помогло в устранении неполадок и проверке корректности работы синхронизации.
Мы ограничили управление этими группами, которые администрируются удалённо, чтобы пользователи не могли вступать в них или покидать их через интерфейс Discourse, но не считали необходимым запретить сотрудникам управлять членством в группах. Мне нравится то, что вы пытаетесь реализовать, но это немного выше моего понимания, честно говоря.
У нас есть клиенты Discourse for Teams, которые активно используют Okta для управления доступом ко всем корпоративным приложениям. Они также настраивают там роли, которые затем используются, например, для предоставления определённого уровня доступа к Microsoft Tableau и другим сервисам. Okta также выступает в качестве каталога, где управляются аватары пользователей, биография, местоположение и другая информация профиля. Им бы хотелось, чтобы эта информация профиля обновлялась в Teams и извне, не только через Okta.
По возможности мы должны стараться не включать сверхтехнические детали в настройки группы. Необходимость давать ссылку на документацию по синтаксису, вероятно, означает, что этот вопрос следует упростить или перенести в настройки администратора сайта. Я считаю, что реализацию этой части лучше доверить каждому плагину аутентификации, так как требования могут сильно различаться.
Возьмем в качестве примера OIDC: этот плагин добавит новый параметр сайта openid_connect_roles_claim. Если используется Okta, администратор настроит его как groups. Я думаю, что формат строкового массива является довольно стандартным для OIDC, но при необходимости мы можем рассмотреть более сложные варианты.
Для получения этой информации атрибуту Auth::Result будет добавлен новый параметр roles, который принимает простой массив строк. Ядро затем обработает это (в Auth::Result#apply_user_attributes!) и загрузит данные в новую таблицу UserAssociatedRoles со столбцами (provider_name, user_id, role). Эта таблица UserAssociatedRoles даст нам «идентификацию источника членства», о которой вы упоминали в первом посте.
Представляю, что настройки группы будут выглядеть примерно так:
Имена ролей будут иметь префикс provider_name. Автозаполнение будет основываться на всех существующих значениях в таблице UserAssociatedRoles, но мы также будем принимать значения, не найденные при автозаполнении, на случай, если роль еще не встречалась в Discourse.
Прелесть наличия полной таблицы user_associated_roles в базе данных заключается в том, что администраторы могут делать с группами Discourse что угодно, а членство будет обновляться мгновенно без необходимости повторного входа пользователей.
Это справедливо. Я считаю, что лучше всего сделать это максимально просто, по крайней мере, для версии 1, поэтому я бы предпочел не иметь нескольких «режимов». Как насчет того, чтобы сделать следующее поведение по умолчанию:
Добавлять участников, когда у них есть соответствующая роль от провайдера аутентификации
Удалять участников, когда эта роль исчезает
Разрешать добавление/удаление участников также в интерфейсе Discourse
Если администратор пытается удалить пользователя, который был добавлен через провайдера аутентификации, показывать предупреждение: «Этот пользователь может быть добавлен снова при следующем входе»
Я думаю, что здесь мы должны стремиться к безопасности по умолчанию и удалять участников, когда они теряют роль у провайдера идентификации. Благодаря улучшениям журнала членства, я надеюсь, что это будет менее запутанно, чем текущее положение дел.
Для сайтов, которые действительно не хотят этого, мы можем добавить параметр сайта, например remove_group_membership_when_auth_role_lost (по умолчанию true).
Да, конечно. У нас также есть эта проблема с другими метаданными пользователя, такими как имя, аватар и т. д. Я думаю, что в ближайшем будущем нам нужно подумать о создании эквивалента sync_sso для других плагинов аутентификации. В него можно было бы передавать всю информацию, которая обычно передается через OIDC / SAML и т. д., включая эту новую информацию о «ролях». Хотя, вероятно, это будет отдельный проект.
Как вам все это звучит, @angus? Это немного менее гибко, чем отдельные строгие/разрешительные режимы, но я думаю, что наличие только одного режима значительно упростит устранение неполадок, документацию и поддержку.
С этим планом вот общее представление о том, как это выглядит с точки зрения администратора:
В Discourse установите параметр openid_connect_roles_claim в значение groups.
Настройка новой группы
Создайте группу в Discourse как обычно. Настройте имя, полное имя, стиль (flair) и т. д. по своему усмотрению.
Перейдите в настройки «Членство», поместите курсор в выпадающий список «Роли SSO» и выберите роль из списка. Если Discourse еще не видел входа пользователя с этой ролью, вам придется ввести её вручную.
Вы можете указать несколько ролей для одной группы Discourse. Например, группа «команда» в Discourse может быть комбинацией oidc:employees и oidc:contractors.
Нажмите «Сохранить», и членство в группе будет мгновенно обновлено с учетом информации о ролях, которую Discourse кэшировал из предыдущих входов.
При будущих входах любые изменения ролей у провайдера идентификации будут отражаться в группе Discourse.
Вы все еще можете добавлять/удалять пользователей в группу через нативный интерфейс Discourse.
Если вы попытаетесь удалить пользователя, который был добавлен через провайдера идентификации, появится предупреждение о том, что пользователь может быть добавлен снова при следующем входе.
Если позже вы решите, что роль IDP больше не должна быть связана с группой, вы можете удалить её, и все пользователи, которые были участниками через эту роль, будут удалены.
Да, однако есть случаи, когда поддержка булевого утверждения (claim) имеет смысл. Но в целом я согласен: пока что давайте оставим всё простым, поддерживая только массив строк.
Реализуя это для каждого аутентификатора отдельно, я предполагаю, что в Auth::Authenticator должен быть метод group_sync_enabled?, который будет переопределяться в конкретных аутентификаторах, а в универсальных аутентификаторах — на основе наличия значения в соответствующей настройке.
Это, кстати, поднимает интересный вопрос. Такой механизм могли бы использовать и специфические сервисные аутентификаторы, например Facebook («groups»?); Google («groups»?) и Discord («roles»?). Не уверен, содержат ли их ID-токены такую информацию, но с точки зрения технического дизайна это стоит рассмотреть (то есть возможность добавить это в будущем). Хотя, думаю, для версии 1 это не является приоритетной задачей.
Такая логика кажется разумной, однако меня интересует, почему мы перешли от термина «groups» к «roles» в данном контексте. Это не критично, но хочу убедиться, что я ничего не упускаю.
С точки зрения UX я вижу риск путаницы из-за использования этой терминологии (то есть одновременного наличия «roles» и «groups»), даже если это основано на полезном техническом различии. Также возможна путаница у разработчиков, которые подойдут к этому без соответствующего контекста.
Мне нравится идея отдельной таблицы, но, возможно, нам стоит использовать внешнюю ссылку на user_associated_accounts вместо provider_name? Это могло бы быть полезно, например, при операциях очистки. Думаю, ответ на этот вопрос частично зависит от того, насколько тесно мы хотим связать ассоциацию групп/ролей с ассоциированной учетной записью с точки зрения продукта. Есть ли какие-либо недостатки в том, чтобы связать их сейчас?
** Редакция: кажется, у нас уже есть такая связь через user_id.
Это звучит нормально, однако я подумал, что у нас уже есть эта информация на уровне провайдера благодаря предложенной вами настройке сайта, которая также покроет случай, когда роль еще не встречалась. Возможно, здесь можно использовать Discourse.authenticators, то есть список провайдеров и их утверждений (claims) в памяти?
Думаю, это хороший компромисс. Особенно если у нас также будет упомянутая ниже настройка сайта.
На уровне плагина (то есть аутентификатора)? Если так, то я согласен. Это должно покрыть эту потребность для версии 1.
Отличное резюме пользовательского сценария С учетом относительно незначительных предложений, которые я сделал, я поддерживаю выбранное направление.
Да, конечно. Я особенно думал о Google, так как люди любят использовать его для своих организаций GSuite, которые, как я предполагаю, имеют некоторую концепцию групп.
Думаю, я пытался избежать путаницы между «Группами провайдера идентификации» и «Группами Discourse»… но возможно, я только запутал всё, изменив название. Я вполне готов остаться на «группах» здесь.
Моя мысль была в том, что мы всё ещё поддерживаем провайдеры аутентификации без управляющего аутентификатора, поэтому записи user_associated_account может не быть. Мы всё равно можем выполнить соединение через user_id, как вы сказали
Не уверен, что параметр сайта поможет здесь. Если мы говорим о массиве строк, представляющих «роли», параметр сайта не укажет, что это за роли. Он только укажет, как получить массив. Имеет ли это смысл?
Да, вы правы. Я всё ещё думал о предыдущей реализации, где я включал конкретные группы непосредственно в настройку, но здесь мы так не делаем, и это нормально.
Думаю, информации достаточно, чтобы начать работу над PR, к которой я приступлю позже на этой неделе, если у вас нет никаких оставшихся возражений? Если в процессе возникнут какие-либо вопросы, я обновлю сообщение здесь.
Хорошо, у меня наконец есть черновая версия, которой я могу поделиться здесь:
Несколько замечаний.
Для первоначальной реализации я выбрал чуть более сложный вариант с группами Google Apps для доменов (hd), так как это помогает продумать возможные комбинации, например, необходимость учёта групп, специфичных для домена, от провайдера.
Чтобы реализовать этот сценарий, мне также пришлось ввести новую концепцию «вторичной авторизации» в момент аутентификации, чтобы обеспечить постепенную авторизацию. Я рассмотрел несколько способов реализации запроса на получение разрешений для групп конкретного пользователя (например, при аутентификации с hd), и этот вариант показался наиболее жизнеспособным. Признаю, что это, возможно, более значительное изменение в этой области, чем ожидалось, но его, пожалуй, стоит обсудить.
Обратите внимание: для реализации работы с группами Google hd необходимо предоставить обычным членам групп Google Apps hd делегированные права администратора, чтобы они могли просматривать свои группы (через API административного каталога). На самом деле существует встроенная «бета»-роль администратора под названием «Groups Reader», которая отлично подходит для этой задачи. Подробнее см. Prebuilt administrator roles | User management | Google Workspace Help
Реализация для Google работает. Если вы настроите её и затем аутентифицируетесь с hd, ваши группы Google hd станут доступны в настройках автоматического членства в группах. Вы будете добавляться в группу Discourse, если выбрана соответствующая группа hd, и удаляться из неё при удалении группы hd (оба действия будут подробно регистрироваться в логах). Последующие пользователи из той же группы Google hd при аутентификации будут добавляться немедленно.
Детали должны быть очевидны из кода и тестов. Вы также заметите, что мне пришлось добавить три новые таблицы. Я пробовал несколько более «лёгких» решений, но они оказались более запутанными и неэффективными при обработке обновлений связанных групп пользователя и связанных групп группы. Избежать создания новых таблиц для каждой задачи сложно. Открыт к идеям в области моделирования данных, а также в целом.
Осталось несколько технических задач (помимо концептуальных и продуктовых вопросов, поднятых выше). Предложения также приветствуются:
Возможно, стоит сериализовать поле label для associated_groups (вместо моделирования на стороне клиента).
Добавить недостающие тесты и юнит-тесты.
Возможно, перенести создание/удаление записей user_associated_group и group_associated_group в фоновую задачу, так как при большом количестве операций это может работать медленно.
Я немного сомневаюсь насчёт идеи «вторичной авторизации», а также столбца provider_domain. Не могли бы вы подробнее объяснить, зачем они нужны? Кажется, что они довольно специфичны для Google… Есть ли причина, по которой мы не можем запросить область видимости admin.directory.group.readonly уже при первом запросе аутентификации? И, возможно, просто добавить префикс с доменом к названию группы? (Или вовсе исключить домен, поскольку я предполагаю, что люди будут использовать это только с одним «хостинг-доменом» Google?)
Да, я полностью согласен с тремя таблицами здесь — это делает структуру чище.
Согласен
Здесь нужно быть осторожными. Любые членства в группах должны быть назначены до того, как пользователь впервые загрузит сайт. Иначе они не увидят специфичные для группы элементы при первом входе (например, защищённые категории). Поэтому я считаю, что изменения в записях user_associated_group должны обрабатываться синхронно.
Однако для изменений записей group_associated_group, думаю, вы правы. Такие изменения могут затронуть тысячи пользователей, поэтому их нужно будет обрабатывать in_batches. Я бы начал с синхронной обработки, добавив в интерфейсе индикатор загрузки. Так администраторы будут чётко видеть, когда процесс запущен и когда завершён.
Если время обработки приблизится к 30 секундам (тайм-аут запроса в unicorn), тогда, возможно, потребуется подумать о фоновой задаче.
Также, возможно, стоит подумать о добавлении блокировки DistributedMutex. Например, что произойдёт, если пользователь войдёт в систему во время обработки изменения group_associated_group? Готов обсудить подобные вопросы на GitHub, как только мы окончательно утвердим общую архитектуру.
Причина, по которой нельзя запрашивать права доступа к группам при первом запросе, в том, что вы ещё не знаете, кто входит в систему, и чем они готовы поделиться. Можно ограничить сопоставление групп Google только пользователями, использующими настройку google_oauth2_hd, однако это существенно сузит функциональность. Команды, использующие Google Apps вместе с «публичными» пользователями, которые также хотят авторизоваться через Google, встречаются довольно часто.
*edit: Уточню, что если вы запросите область доступа к группам, а пользователь не сможет её предоставить (например, его HD не делегировал права неадминистративным пользователям, как описано выше), то авторизация не удастся. Нельзя запрашивать необязательные области доступа одновременно с обязательными.
Более того, такой подход, то есть запрос области доступа к группам сразу в качестве стандартной практики при реализации в различных методах аутентификации, можно считать даже более специфичным для Google, чем альтернативный вариант, так как не всегда существует аналог системы хостинговых доменов для ограничения входа. Например, я могу ошибаться, но, кажется, нет способа ограничить вход через Github OAuth2 конкретной организацией Github.
Другими словами, во многих случаях вам придётся выбирать между тем, чтобы требовать от всех пользователей, использующих этот метод аутентификации, предоставить соответствующую область groups, или вообще не использовать функцию. Такой подход может работать в некоторых контекстах, но не во многих. Подход с инкрементальной авторизацией предоставляет разным методам аутентификации больше гибкости при реализации функции.
Верно, что Google активно продвигает инкрементальную авторизацию в сфере OAuth2; например, все рабочие документы по этой теме написаны сотрудником Google.
Однако сама концепция не специфична для Google (другие не обязательно называют это «инкрементальной авторизацией»). Она довольно распространена в различных формах в мобильных приложениях и внедряется другими провайдерами в OAuth2. Например, вот документация Facebook по той же теме.
Вы, вероятно, уже знакомы с этой областью, но считается «хорошей практикой»:
сообщать пользователям, что вы собираетесь запросить больше разрешений, чем стандартная базовая информация;
и, возможно, объяснить почему.
Если пользователь нажал «Зарегистрироваться через Facebook» в форме входа Discourse, а затем, помимо адреса электронной почты, его также попросили предоставить доступ к его группам Facebook, он может отказаться от регистрации. Facebook формулирует это так:
Как общее правило, чем больше разрешений запрашивает приложение, тем меньше вероятность, что люди будут использовать Facebook для входа в ваше приложение. Фактически, наши исследования показывают, что приложения, запрашивающие более четырёх разрешений, испытывают значительное падение количества завершённых входов.
Это поднимает вопрос о том, правильно ли вообще запрашивать дополнительные области доступа в момент аутентификации, и в целом я пришёл к выводу, что у нас нет других хороших вариантов. В некоторых сценариях необходим немедленный доступ к группам (как вы и намекнули), а также есть реальность: без запроса «на берегу» многие пользователи не предпримут дополнительный шаг для авторизации своих групп в сервисе, например, в своём профиле или на странице групп.
Это должно быть сделано в момент аутентификации, что возвращает нас к проблеме, упомянутой выше, и объясняет, почему я реализовал систему «вторичной авторизации». Она действительно задумана как лёгкая «система» в том смысле, что другим сервисам, например Facebook или Github, относительно легко реализовать запрос вторичной авторизации для получения доступа к группам пользователя после того, как он аутентифицировался, и, возможно, после прохождения определённой проверки на основе его базовой информации.
Каждому провайдеру достаточно:
вернуть результат с полем secondary_authorization_url;
использовать параметр state для определения, на каком этапе запроса авторизации находится пользователь;
предоставить omniauth_secondary_authorization_description для users/omniauth_callbacks/secondary_authorization.html.erb. Например, вот текст для Google, который пользователь видит перед подтверждением перенаправления для вторичной авторизации:
Поскольку вы вошли с адресом электронной почты %{domain}, нам нужно запросить разрешение на просмотр ваших групп %{domain}.
Ни одна из этих частей не специфична для Google.
Я бы хотел реализовать возможность для пользователя сказать «нет» вторичному запросу и при этом всё равно пройти аутентификацию. В сценарии Google Apps HD это не является серьёзной проблемой, так как, если их учётная запись принадлежит хостинговому домену, они вряд ли захотят или смогут отказаться. Однако, я думаю, следует предусмотреть поддержку всего спектра сценариев аутентификации.
Наконец, стоит отметить, что вторичная авторизация не является необходимой для работы associated_groups. Провайдер аутентификации может просто запросить область доступа к группам сразу и затем добавить группы в результат аутентификации после получения первого ответа. Действительно, мы, вероятно, должны реализовать это как опцию для базовых плагинов oauth2 и openid connect.
Домен провайдера
Я считаю, что в таблице associated_groups должен быть какой-то дополнительный идентификатор, доступный для чтения администратором сайта. Существует ряд сценариев, в которых одного имени группы может быть недостаточно. Возможны конфликты имён в эквивалентных понятиях разных сервисов, например:
управление группами в нескольких доменах Google (в одном рабочем пространстве также может быть несколько доменов);
управление группами в нескольких организациях Github;
управление ролями на нескольких серверах Discord
и так далее.
Мы могли бы переименовать domain в namespace. Мы могли бы включить его в поле name группы, но дало бы это какие-то преимущества? Возможно, будет полезно выполнять запросы по «домену» или «пространству имён» в будущем. Да, возможно, namespace будет лучше, чем domain.
Причина, по которой он должен быть «доступен для чтения администратором», в том, что он используется в метке, видимой администратору в интерфейсе групп, частично для целей устранения неоднозначности.
Я размышляю, имеет ли смысл попытаться также хранить здесь provider_id (если он существует). Возможно, это будет полезно в будущем.
Да, согласен со всем этим, спасибо за советы. Я попробую реализовать эту часть, и мы обсудим её подробнее в PR.
@david Я только что добавил несколько обновлений по этой задаче, включая:
DistributedMutxes и in_batches в group_associated_group
Тесты на принятие (у нас уже был rspec)
Без сомнения, потребуется ещё некоторая доработка, но сейчас всё работает в соответствии со спецификацией, и все тесты проходят. Попробуйте запустить, дайте знать, что вы думаете и какие изменения вы бы хотели внести.
Привет, @angus! Мне интересно, есть ли у вас какие-либо новые успехи в этом вопросе? Я очень заинтересован в простом поведении «strict», насколько я понимаю, и, поскольку мы контролируем нашего провайдера Oauth2/OpenID Connect, меня не беспокоит случай «вторичной авторизации». Есть ли шанс, что что-то подобное появится раньше?
Если это поможет, наша среда описана здесь: Infrastructure/Authentication - Fedora Project Wiki, и я настроил Discourse так, чтобы запрашивать oauth2-область openid profile email https://id.fedoraproject.org/scope/groups.
В общем, я хочу следующее:
Не трогать уровни доверия и группы сотрудников
Добавить пользователя в любые существующие группы Discourse из списка SSO, если их там ещё нет
Удалить пользователя из любых групп, в которых он состоит, но которых нет в списке
Я открыто признаю, что не понимаю всех тонкостей… Есть ли какая-то сложность, которую я не учитываю?
Отлично — огромное спасибо. Я не хочу надоедать, но поддержка Discourse посоветовала, что лучший способ узнать текущую ситуацию — это написать в этой теме.
Я с нетерпением жду вашей работы над этим, потому что как только мы получим это, у нас появится множество возможностей для сайтов Fedora на Discourse, которые сейчас просто недоступны!
С учетом относительно незначительных предложений, которые я сделал, я поддерживаю выбранное направление.
