hist_rights.md

Overview

Chaque utilisateur a un certain niveau de droit sur chaque groupe. Ce niveau de droit indique ce qu'il a le droit de savoir et de faire.

Les differents niveaux de droit [specification de actions.graphql]

Par rapport à un groupe donné, un user peut avoir différents niveaux de droits :

• none : ne sait meme pas que le groupe existe, aucun autre droit (typiquement, une connection où l'utilisateur ne s'est pas authentifié)
• authenticated : sait que le groupe existe, aucun autre droit (une connection on-platal sans auth, ou une connection authentifiée)
• viewer : le user a aussi accès à l'activité publique du groupe : frontpage, Q&A, liste des membres, speakers et admins, Message dont le groupe est destinataire
• member : le user a aussi acces à l'activité interne du groupe : les PrivatePost, ainsi que les Message dont le groupe est auteur
• speaker : le user peut aussi parler au nom du groupe. Il a le droit de publier des annonces et d'organiser des évènements
• admin : le user a tous les droits sur le groupe

Le graphe organique des groupes

Les champs parent et children de l'objet Group dans le schéma GraphQL définissent un graphe des groupes, appelé graphe organique des groupes car il définit les héritages de droits d'admin (l'admin d'un groupe peut administrer les groupes enfants) (de la même facon qu'une hiérarchie organique militaire). Ce graphe ne doit pas contenir de cycles, i.e. doit être un arbre.

Conditions pour les niveaux de droit

Un des rôles du graphe organique des groupes est de définir le niveau de droit des users pour chaque groupe.

D'abord, petit détail de terminologie : les cinq niveaux de droits sont inclus les uns dans les autres (un speaker est aussi un viewer, par ex.) (sauf pour les permissions héritées)

Plus précisément, on a les inclusions suivantes : admin strict > speaker > membre strict > membre hérité > viewer > authenticated. Il n'y a que admin hérité qui n'est pas nécessairement inclus dans les autres niveaux de droits.

Dans la BDD sous-jacente, il faut que pour chaque groupe, on ait admin > speaker > member.

Détaillons ici les conditions exactes pour avoir un niveau de droit donné.

Pour les groupes simples

• Member :
  • Un user est membre strict du groupe G s'il est member de G selon la BDD sous-jacente.
  • Un user est membre hérité du groupe G s'il est membre strict d'un de ses descendants.
• Speaker : un user est speaker du groupe G s'il est speaker de G selon la BDD. Pas de notion d'héritage de speaker.
• Admin :
  • Un user est admin strict du groupe G s'il est admin de G selon la BDD.
  • Un user est admin hérité du groupe G s'il est admin strict d'un de ses ascendants.
• Viewer : un user est viewer du groupe G
  • s'il est membre hérité de G.
  • s'il est membre hérité d'un groupe immédiatement parent de G (one-edge-down visibility), ou
  • s'il est membre hérité d'un groupe faisant partie du champ "visibilityEdge" de G
  • s'il est membre d'un métagroupe dont G est membre (implicit visibility-edges).
• Dans tous les autres cas, le user a le niveau de droits "none" ou "authenticated", selon le cas de figure.

Pour les méta-groupes

• Un user est membre d'un méta-groupe G s'il est membre (hérité) d'un groupe simple dans G.
• Un user est speaker d'un méta-groupe G s'il est speaker d'un groupe simple dans G.
• Un user est admin d'un méta-groupe G s'il est admin (hérité) d'un groupe simple dans G.
• Un user est viewer d'un méta-groupe G s'il est viewer d'un groupe simple dans G.

L'autre rôle du graphe organique des groupes est de permettre l'administration "en cascade" des groupes enfants.

Si un groupe est le parent d'un autre, alors les admins du groupe parent sont admins (hérités) du groupe enfant. Exemples :

• BR est parent de Chocapix. L'admin de Chocapix est parti en vacances. L'admin de BR peut, en tant qu'admin (hérité) de Chocapix, faire ce qu'il a à faire, sans attendre le retour du respo Chocapix.
• Cotisants-Kès est parent de Troll'X. Troll'X fait n'importe quoi (en floodant de Messages par ex). Les admins de Cotisants-Kès (les kessiers) peuvent, comme ils sont admins hérités de Troll'X, stopper les dégâts.

Remarque sur speaker : Il s'agit d'un nouveau niveau de droit par rapport à Frankiz 3.0 ; qui est a présent implémenté sur le LDAP bloaziadur.

Dans l'implémentation

Le système GraphQL est pensé comme l'interface par laquelle les utilisateurs interagissent avec sigma, les graphismes en moins. Le client peut envoyer tout type de requête. C'est au niveau des resolvers que les permissions sont gérées. D'où le @rights

Dans les resolvers GraphQL : le tag @rights

Utilise par JSDoc Le tag @rights est la gestion des autorisations. Utilise dans resolvers.ts

Certaines fonctions de connectors effectuent des vérifications d'authorizations avant de renvoyer une réponse, d'autres non. Pour être sur qu'on ne renvoie jamais de réponse sans avoir au préalable effectué les bonnes vérifications, chaque fonction possède dans sa description un attribut droit, qui décrit les droits que requiert cette fonction.

La valeur de @rights peut être :

• super - la fonction n'effectue aucune vérification, et renvoie le resultat demandé
• admin( groupID ) - la fonction ne fait que ce qu'un admin du groupe indiqué aurait le droit de faire
• speaker( groupUID ), member( groupUID ), viewer( groupUID ) - même chose
• user - la fonction ne fait que ce que l'utiliateur a le droit de faire (vérifications via l'argument user)

La procédure a suivre est la suivante : quand une fonction possède un certain niveau de droit, elle ne peut appeler une fonction possédant un niveau de droit plus large que si :

• 1- on a au préalable vérifié que l'utilisateur possédait effectivement ces droits. ou
• 2- on s'est assuré que l'opération effectuée par cet appel particulier de la fonction était dans les droits de l'utilisateur

D'un point de vue pratique :

• les resolvers doivent vérifier que le user possede les droits énoncés dans le tag @rights, avant de renvoyer un résultat / modifier la BDD. Ils vérifient aussi que le user possede les droits nécessaires pour appeler des fonctions dans les models.
• les fonctions dans les models peuvent supposer que les droits du tag @rights sont acquis, ie. qu'ils ont été vérifiés par la fonction appelante au préalable.

Quel @rights donner a quels resolvers ?

Les resolvers de base de mutation et query ont des droits user.

Les fonctions qui ne modifient pas la BDD et ne renvoient pas de données sur la BDD n'ont pas de rights.

Le cas des Requests

cf objects.graphql

Les Mutations concernant les Requests suivent à peu près toutes le schéma suivant :

• <typeAuteur>Request<NatureDeLaRequest>(auteur, destinataire, comment): Request
• accept<NatureDeLaRequest>Request(request: ID!, comment: String): Boolean
• refuse<NatureDeLaRequest>Request(request: ID!, comment: String): Boolean
  • le paramètre est le rid de la Request à accepter ou refuser
  • seul les admins du groupe destinataire peuvent accepter ou refuser une Request

Les Mutations concernant les Messages suivent à peu près toutes le schéma suivant :

• create<TypeDeMessage>(auteur, destinataire, title, content, etc.): <TypeDeMessage>
• edit<TypeDeMessage>(<typeDeMessage>ToEdit: ID!): <TypeDeMessage>
• remove<TypeDeMessage>(<typeDeMessage>ToRemove: ID!): Boolean
  • = l'auteur supprime le message
  • pour les Messages où l'auteur est un utilisateur, seul l'auteur a le droit de remove son Message
  • pour les Messages où l'auteur est un groupe, n'importe quel admin du groupe (ou speaker selon le cas) a le droit de remove le Message
• censor<TypeDeMessage>(<typeDeMessage>ToCensor: ID!): Boolean
  • = le groupe destinataire supprime le message
  • n'importe quel admin du groupe a le droit de censurer un Message qui lui est adressé
  • (le destinataire est un Group pour tous les Messages)