Ok, j’ai enfin une version en cours de développement à partager ici
Quelques remarques.
J’ai choisi le cas légèrement plus complexe des groupes Google Apps hd pour la première implémentation, car cela aide à réfléchir aux différentes permutations possibles, par exemple la nécessité de prendre en compte les groupes spécifiques à un domaine provenant d’un fournisseur.
Pour implémenter ce cas d’usage, j’ai également dû introduire un nouveau concept d’« autorisation secondaire » au moment de l’authentification, afin de permettre une autorisation incrémentale. J’ai envisagé plusieurs façons de demander des autorisations de groupe spécifiques pour un utilisateur (c’est-à-dire s’il s’authentifie avec un hd), et cela semblait être la solution la plus faisable. Je reconnais que cela représente peut-être un changement plus important que prévu de ce côté-là, mais il vaut peut-être la peine d’en discuter.
Notez que pour implémenter le cas des groupes Google hd, vous devez accorder aux membres non administrateurs de vos groupes Google Apps hd une autorité d’administrateur déléguée afin de pouvoir lister leurs groupes (via l’API du répertoire administrateur). Il existe en réalité un rôle d’administrateur préconstruit « bêta » appelé « Lecteur de groupes » qui fonctionne bien pour cela. Voir Prebuilt administrator roles | User management | Google Workspace Help
L’implémentation Google fonctionne. Si vous la configurez puis vous authentifiez avec un hd, vos groupes Google hd seront disponibles dans le paramètre d’appartenance automatique aux groupes ; vous serez ajouté à ce groupe Discourse si ce groupe hd est sélectionné, retiré s’il est supprimé (avec ces deux actions enregistrées avec une certaine précision), et les utilisateurs ultérieurs de ce groupe Google hd qui s’authentifieront seront ajoutés immédiatement.
Les détails devraient être évidents à partir du code et des tests. Vous remarquerez également que j’ai fini par ajouter trois nouvelles tables. J’ai essayé quelques solutions plus « légères », mais elles se sont toutes révélées plus compliquées et inefficaces lorsqu’il s’agissait de gérer les mises à jour des groupes associés à un utilisateur et des groupes associés à un groupe. Il est difficile d’éviter de créer de nouvelles tables pour chacun. Je suis ouvert aux idées concernant la modélisation des données, et plus généralement.
Quelques tâches techniques restantes (en dehors des questions conceptuelles/produit soulevées ci-dessus). Des suggestions sont également les bienvenues à ce sujet :
- Peut-être sérialiser le
labeldesassociated_groups(au lieu de le modéliser côté client). - Ajouter les tests manquants et les tests QUnit.
- Peut-être déplacer la création/destruction de
user_associated_group/group_associated_groupvers un travail en arrière-plan, car avec un grand nombre d’entrées, cela pourrait être lent.