Qu'est-ce que le contrôle d'accès ? 
Avec FastComments SSO Access Control, parfois appelé RBAC, les utilisateurs peuvent se voir limiter l'accès à certaines pages ou fils de commentaires. De plus, les utilisateurs ne peuvent @mention que des membres du même groupe.
En détail
Nous pouvons placer des Users et, facultativement, des Pages dans des groupes.
Lorsque des Users sont placés dans des groupes, et que Limit Comments by SSO User Groups est activé dans les Paramètres du widget, alors les utilisateurs ne verront que les commentaires d'utilisateurs appartenant aux mêmes groupes et ne pourront @mention que des utilisateurs du même groupe.
De plus, des Pages peuvent être placées dans des groupes, et alors les utilisateurs ne pourront accéder qu'aux commentaires des pages auxquelles ils ont accès.
Nous appelons cela des groupes de "User-Level" par opposition aux groupes de "Page-Level".
Alors, lequel vous convient le mieux ?
Use User-Level Groups if...
- Vous souhaitez utiliser la même valeur
urlId(URL de la page ou ID d'article), mais restreindre les commentaires par groupe. - Par exemple, vous souhaitez avoir des groupes "New User" et "Veteran User", et ils ne devraient jamais voir les commentaires des autres sur les mêmes pages.
Use Page-Level Groups if...
- Vos groupes ont des pages spécifiques.
- Par exemple, les utilisateurs du groupe "Public Pages" ne devraient jamais consulter les articles "Top Secret".
Comment ça fonctionne
Le contrôle d'accès de FastComments fonctionne en assignant Pages et Users aux groupes souhaités.
Un groupe est simplement un identifiant de chaîne, comme GREEN ou abc-123.
Users et Pages ne sont pas limités à un seul groupe. Ils sont limités à 100 et 1000 groupes, respectivement.
Accès aux pages non autorisées
Si un utilisateur tente d'accéder à une page à laquelle il n'a pas accès, il verra un message d'erreur, comme ci-dessous :
Le texte du message peut être personnalisé.
La spécification
Définir la façon dont plusieurs utilisateurs interagissent, et le tester, est compliqué. Voici la spécification suivante que nous suivons pour le contrôle d'accès, que vous pouvez utiliser pour tester votre implémentation :
Page avec null group ids, utilisateur avec null group ids - devrait avoir accès.
Page avec null group ids, utilisateur avec group ids - devrait avoir accès.
Page avec group ids, utilisateur avec null group ids - devrait avoir accès.
Page avec group ids, utilisateur avec liste vide - ne devrait PAS avoir accès.
Page avec group ids, utilisateur avec group ids - l'intersection existe - devrait avoir accès.
Page avec group ids, utilisateur avec group ids - l'intersection n'existe pas - ne devrait PAS avoir accès.
Page avec liste vide de group ids (personne n'a accès), utilisateur avec null - ne devrait PAS avoir accès.
SSO User A = Aucun group ids défini (null = accès complet).
SSO User B = Aucun group ids défini (null = accès complet).
A peut @B.
SSO User A = Aucun group ids défini (null = accès complet).
SSO User B = Group ids définis.
A peut @B.
SSO User A = Group ids définis.
SSO User B = Aucun group ids défini (null = accès complet).
A peut @B.
SSO User A = Group ids = [a].
SSO User B = Group ids = [b].
A ne peut PAS @B.
SSO User A = Group ids = [a].
SSO User B = Group ids = [a, b].
A peut @B.Implémentation
Mentionner des utilisateurs d'autres groupes
Si deux utilisateurs appartiennent à deux ensembles de groupes différents, et qu'il n'y a aucune intersection, ils ne pourront pas se @mentionner.
Si un utilisateur tape manuellement un @mention et soumet son commentaire, il restera sous forme de texte brut. L'autre utilisateur ne sera pas étiqueté.
Maintien des groupes
Groups sont définis en utilisant respectivement les ressources API Pages et SSOUsers.
L'API Pages peut être appelée pour définir l'ensemble des groupes autorisés à accéder à la page. Par défaut, tous les groupes, ainsi que les utilisateurs qui n'appartiennent pas à un groupe, ont accès.
De même, l'API SSOUsers peut être appelée pour définir les groupes associés à chaque utilisateur.
Pour les deux ressources, il n'y a aucune limitation quant au moment où les groupes peuvent être définis ou mis à jour.
Si l'on souhaite uniquement empêcher les utilisateurs de se @mentionner mutuellement, alors il n'est pas nécessaire de prendre en compte les Pages.
Remarque !
Defining and updating the SSO user groups does not require using the API, and can instead be updated automatically by defining the group ids in the SSO payload passed to the comment widget. However, for large lists of groups, this is not recommended as the user would have to submit this payload for every page load.
Exemples d'appels d'API
Nous allons parcourir l'appel à l'API FastComments pour configurer le contrôle d'accès.
Avant de commencer, notez que nous n'avons pas à créer explicitement une structure Group. Les groupes sont simplement des identifiants
ajoutés aux Users et aux Pages. Ajouter un groupe à un utilisateur ou à une page « crée » automatiquement le groupe.
Premièrement, créons deux utilisateurs, User A et User B; nous allons les placer dans Group X :
Créons maintenant une Page. Nous l'appellerons Confidential Page, et jusqu'à présent aucun de ces utilisateurs n'y aura accès car elle sera dans le groupe CONFIDENTIAL :
Les utilisateurs A et B n'ont actuellement PAS accès à la nouvelle page. Cependant, puisqu'ils appartiennent au même groupe, GROUP-X, ils peuvent @mention l'un l'autre.
Mettons à jour User B pour qu'il puisse maintenant accéder à la page :
User B appartient maintenant aux deux groupes. Nos utilisateurs peuvent toujours @mention l'un l'autre, mais seul User B peut voir notre page confidentielle.
Faisons en sorte que User B puisse uniquement voir la page confidentielle :
Ils peuvent désormais voir la page confidentielle, mais aucun de nos utilisateurs ne peut se @mentionner, car ils sont dans des groupes différents.
Cependant, tout utilisateur qui n'est pas soumis au contrôle d'accès pourra accéder à notre page. Pour l'empêcher, assurez-vous qu'aucun utilisateur SSO n'ait ses groupIds définis à null. Par exemple, créons User C, qui a accès à tout :
En définissant groupIds sur null, nous indiquons qu'ils ne sont pas limités par le contrôle d'accès.
Maintenant, créons une page à laquelle tout le monde a accès :
En définissant accessibleByGroupIds sur null, nous indiquons que cette Page n'est pas soumise au contrôle d'accès, et que les deux utilisateurs peuvent y accéder.
Ceci conclut notre présentation de l'API pour le contrôle d'accès.