Annexes
Vérifier les accès d'un utilisateur
Cette annexe décrit comment lire les accès réellement appliqués à une session, pour lever un doute entre ce qui est paramétré et ce que la personne obtient. Elle sert aux vérifications produit et aux tests de recette; les règles elles-mêmes sont décrites dans Calcul des droits d'accès.
Vérifier les accès d'un utilisateur
Cette annexe décrit comment lire les accès réellement appliqués à une session, pour lever un doute entre ce qui est paramétré et ce que la personne obtient. Elle sert aux vérifications produit et aux tests de recette; les règles elles-mêmes sont décrites dans Calcul des droits d'accès.
Où regarder
Les accès d'une session se lisent dans la réponse de l'appel loggeduser, visible depuis l'onglet réseau des outils de développement du navigateur, section « Preview ». L'onglet « Payload » montre ce que le frontal a envoyé, « Preview » ce que la plateforme a répondu.
Ce que contient la réponse
| Champ | Ce qu'il donne |
|---|---|
sessionAccessRights | Les accès appliqués à la session, séparés par shop : contrats, profil de la personne et, après un changement d'organisation, organisation active et droits délégués. Une liste par shop, identifiée par son short ID |
accessKeys | Les accès personnalisés de la personne, rangés par organisation. null, ou aucune entrée pour son organisation : pas de personnalisation en cours, les accès viennent des rôles métier ou du mode Admin. Une liste : ce sont exactement ces accès qui s'appliquent; une liste vide ne donne aucun accès |
allSessionAccessRights | L'ensemble des accès de la session, tous shops confondus |
roles | Les niveaux d'accès portés par les contrats de l'organisation de la personne (par exemple ADMIN). Les rôles métier se lisent dans meta.businessRoles |
activeOrganisationShortId | L'organisation pour laquelle la personne agit, quand elle a changé d'organisation |
switchableOrganisations | Les organisations proposées par « Changer d'organisation ». Pour une organisation mandante, procuration.roles donne les droits délégués et procuration.rights les accès calculés par shop |
descendantOrganisations | Les organisations descendantes de l'organisation de la personne |
Points de vigilance
- Une personne qui reçoit des accès dans les deux shops a deux listes distinctes dans
sessionAccessRights. Un accès présent dans un shop ne vaut pas pour l'autre. - Un
accessKeysnon vide explique à lui seul qu'un rôle attribué reste sans effet : le mode personnalisé prime sur les rôles. - Un accès personnalisé qui ne figure plus dans aucun contrat de l'organisation est ignoré au calcul, sans être retiré de la fiche.
- Une liste personnalisée vide pour l'organisation de la personne explique une absence totale d'accès, alors que les écrans d'accès affichent la personne en Admin ou en Rôles.
- Après un changement d'organisation vers une organisation mandante, un accès manquant vient souvent des droits délégués : comparer
sessionAccessRightsavecprocuration.rolesdansswitchableOrganisations. Le calcul est décrit dans Procurations et organisations complexes.