Fermer

mai 21, 2020

Pourquoi utiliser la vue des autorisations principales dans AEM


Avant AEM 6.5, nous n'avions vraiment qu'une seule interface utilisateur pour gérer les autorisations des utilisateurs. Cela ne veut pas dire que nous ne pouvions pas accéder directement à JCR et définir des ACL, mais l'écran d'administration utilisateur était simplement plus simple.

Par exemple, prenez cet exemple dans la console d'administration utilisateur classique.

 Autorisations classiques

En général, cela signifiait que nous vérifions le dossier racine pour donner la lecture à tout le monde. Cela est dû au fait qu'un utilisateur AEM ne peut pas faire grand-chose sans accéder à «/ bin» qui se trouve directement sous le nœud racine et que vous ne pouvez pas ajouter directement des autorisations au bac.

Cette «lecture» se répercuterait sur tous des autres nœuds. Ainsi, lorsque vous vouliez supprimer l'accès, vous décochez la case, vous avez maintenant ajouté une stratégie de refus.

 Expérience client et conception - Créez une meilleure expérience client avec AEM sur Microsoft Azure

Avez-vous déjà accidentellement vérifié un boîte, enregistrée, puis décochée? Vous venez de créer un autre refus. La seule solution pour le supprimer est d'aller supprimer la politique. Même si vous supprimez l'utilisateur, cette stratégie de refus persistera.

Les refus provoquent non seulement un encombrement inutile, mais rendent également le dépannage des problèmes d'autorisation beaucoup plus difficile. C'était une approche très impure à laquelle nous nous sommes adaptés. Maintenant, nous avons une meilleure option dans AEM pour gérer les autorisations.

Touch UI Permissions Console

Avec l'introduction de la Touch UI Permissions Console, vous pouvez maintenant définir vos stratégies pour vos principaux. Vous avez également la possibilité de créer facilement des exceptions via l'interface utilisateur.

En utilisant l'exemple précédent, voici à quoi cela ressemble dans la console des autorisations.

 Autorisations Touchui [19659002] Vous avez toujours la «lecture» à la racine, mais vous pouvez maintenant créer un glob sur ce nœud. Rep: glob = ”” définit les autorisations de lecture sur lui-même uniquement. Cela signifie que tous les nœuds directement liés à la racine seront lisibles, mais les sous-dossiers seront exclus et n'hériteront pas de la lecture. Cela vous donne plus de contrôle sur les autorisations que vous devez définir sans avoir à vous soucier des autorisations «accidentelles».

J'ai fait la même chose sur «/ content» car les auteurs obtiendront des autorisations sur des zones spécifiques via d'autres groupes. Encore une fois, pas besoin de créer un refus.

Bien que ce ne soit pas une véritable implémentation d'autorisation principale, car sous le capot, il crée toujours les stratégies pour les chemins, c'est un grand pas en avant pour la gestion des autorisations à un niveau plus granulaire.

En savoir plus à ce sujet sur le site Web Adobe .




Source link