Permissions granulaires basées sur les groupes pour les utilisateurs anonymes et connectés

Nouvelles et événements Annonces
1

Il existe dans notre base de code un pseudo-groupe historiquement déroutant appelé @everyone, qui peut être utilisé pour :

  • Les paramètres du site de type group_list
  • Les permissions des catégories
  • Les groupes d’étiquettes

Dans certains cas, les personnes interprètent @everyone comme signifiant « tous les utilisateurs anonymes et tous les utilisateurs connectés », tandis que d’autres le comprennent comme signifiant uniquement « tous les utilisateurs connectés ». En réalité, pour les paramètres du site, cela signifie généralement « tous les utilisateurs connectés ».

La situation est encore plus confuse du fait que ce groupe @everyone peut être utilisé sur des paramètres du site où il n’a aucun sens d’accorder l’accès à « tous les anonymes et tous les connectés », comme c’est le cas pour pm_tags_allowed_for_groups.

Cela crée également de la confusion du point de vue de la gestion des fonctionnalités (feature flagging) et de l’expérience développeur, car pour certaines modifications à venir ou d’autres paramètres, nous pourrions réellement souhaiter les activer pour « tous les anonymes et tous les connectés ».

Solution

Nous introduisons deux pseudo-groupes automatiques distincts :

  • anonymous_users (ID 4) – Représente les utilisateurs anonymes visitant votre site sans compte
  • logged_in_users (ID 5) – Représente tous les utilisateurs connectés à votre site, avec un effet similaire au groupe automatique trust_level_0, mais plus spécifique

Ces groupes ont déjà été introduits, mais ne prendront effet que lorsque la modification à venir granular_anonymous_and_logged_in_groups_permissions sera activée sur votre site.

Lorsque cette modification à venir sera activée, tout paramètre ayant everyone comme groupe sélectionné sera automatiquement traduit vers l’ID logged_in_users. Ainsi, aucune donnée dans la table des paramètres du site ne sera modifiée lors de l’activation de cette modification. Lorsque celle-ci deviendra permanente, nous effectuerons une migration des données pour tous les paramètres de groupe afin d’appliquer ce changement.

De plus, nous avons marqué anonymous_users comme disallowed_group pour plusieurs paramètres du site où cela n’a pas de sens, par exemple personal_message_enabled_groups.

image
image1217×205 51.6 KB

Les conflits avec des noms de groupes existants sont gérés automatiquement, en renommant les groupes existants et en mettant à jour les mentions de groupes dans les publications.

Qu’en est-il des permissions des étiquettes et des catégories ?

Ces permissions resteront inchangées, car leur notion de « everyone » diffère à plusieurs égards et ne repose pas sur le groupe automatique sous-jacent.

8 « J'aime »
Db:seed_fu fails on 002_groups.rb during upgrade: Validation failed: Name has already been taken
3

Attends… quoi :flushed_face: Cela signifie-t-il que toutes les catégories actuellement publiques (tout le monde) passeront à des catégories fermées nécessitant une connexion, une fois cette option activée ?

4

Non, car :

Cela affecte uniquement les paramètres du site de type liste de groupes qui permettent actuellement de sélectionner « tout le monde » comme suit :

image
image909×273 54 KB

1 « J'aime »
5

Peut-être que quelqu’un peut m’aider à comprendre comment je dois ajuster les composants de mon thème ?

J’ai essayé d’utiliser le composant copy-post comme exemple, car je me souviens qu’il utilise également un paramètre de groupe qui accorde l’accès à la fonctionnalité. Et qu’il y avait un problème car le pseudo-groupe « everyone » nécessitait une vérification distincte, tout comme dans mon composant, car comparer les IDs des groupes auxquels l’utilisateur appartient ne suffit pas — ces IDs doivent être vérifiés séparément. C’est pourquoi je m’attendais à un changement récent là-bas, car, à ma connaissance, les nouveaux groupes sont aussi des pseudo-groupes et l’ID doit être vérifié séparément. Est-ce que je manque quelque chose qui expliquerait pourquoi ce n’est pas nécessaire ici ?

Mon composant favorite filters dispose de deux paramètres de groupe : l’un permet aux groupes d’enregistrer leurs propres filtres, et l’autre propose des filtres standard.
Par défaut, seuls les membres du groupe trust_level_0 peuvent utiliser des filtres personnalisés, car seuls les utilisateurs enregistrés peuvent avoir des données stockées dans un champ utilisateur personnalisé. Donc, ici, il serait logique que je n’autorise pas anonymous_users comme sélection. Comment puis-je faire cela dans un composant de thème ? Existe-t-il déjà un exemple pour cela ?

Le paramètre par défaut pour les filtres par défaut est « everyone », car je trouve utile que même les utilisateurs non enregistrés puissent voir et utiliser les filtres par défaut. Le problème est que everyone change en « logged_in_users » même si je l’ai spécifiquement sélectionné. Dois-je créer une migration personnalisée pour cela afin que les administrateurs utilisant actuellement everyone continuent d’avoir des filtres pour les utilisateurs non enregistrés à l’avenir ? Quand cette migration doit-elle avoir lieu ? Ou chaque administrateur doit-il modifier cela individuellement après que vous ayez exécuté la migration ?

Tout ce dont je m’inquiète est-il réellement inutile ? Si des ajustements sont nécessaires, moins de quatre semaines semblent être un délai assez court compte tenu du nombre de composants maintenus par la communauté qui pourraient potentiellement être affectés.
En plus de « copy-post », j’ai également examiné le composant unanswered filter, mais je n’ai trouvé aucun changement là non plus. J’ai l’impression d’oublier quelque chose d’important. Après tout, le changement est activé par défaut depuis presque une semaine maintenant. C’est pourquoi je suppose que les composants officiels auraient déjà été mis à jour si des ajustements étaient nécessaires.

1 « J'aime »
6

3 messages ont été fusionnés dans un sujet existant : Modernisation du thème Foundation

7

En examinant ces composants, currentUser?.groups n’est pas fiable de toute façon, car il ne comprend que les groupes visibles pour l’utilisateur, et les groupes dans lesquels il se trouve et qui influencent les autorisations peuvent ne pas être sérialisés ici :

Nous contournons cela dans le noyau et les plugins en procédant comme ceci dans le sérialiseur de l’utilisateur actuel :

Mais évidemment, cela n’est pas disponible pour les composants de thème et les thèmes, ni pour leurs paramètres.

Hmm, je ne suis pas sûr, je devrai y réfléchir. Si vous vouliez vraiment dire everyone, alors cela devrait changer à la fois en logged_in_users ET en anonymous_users. C’était le principal problème avec everyone tel que mentionné dans le message original — certaines personnes l’ont interprété comme signifiant uniquement les utilisateurs connectés, d’autres comme signifiant les utilisateurs connectés + anonymes, et cela dépendait beaucoup de la situation.

J’ai choisi l’interprétation « uniquement les utilisateurs connectés » car elle était plus sûre d’un point de vue sécurité.

Non, j’ai simplement oublié les composants de thème et les thèmes, ainsi que leurs paramètres et la façon dont ils seraient affectés par ce changement. J’étais surtout concentré sur les paramètres du site. Des choses comme celle-ci seront particulièrement difficiles à trouver, car elles n’utilisent même pas la constante AUTO_GROUPS :

image

Quoi qu’il en soit, je vais réfléchir à des solutions à ces problèmes, et je ne passerai pas ce changement à la version Stable tant que je n’aurai pas trouvé de solutions.

2 « J'aime »
9

Petit update, j’ai une idée sur la manière de gérer ça, et nous en discutons en interne. J’espère que ça ne prendra pas trop de temps :crossed_fingers:

1 « J'aime »