Administrateur de configuration des rôles

PortalRoleAdmin est la page d’administration des rôles du portail : quels rôles possède le portail, et lesquels un nouvel utilisateur enregistré est attribué. Il est livré avec le framework sur les deux piles, donc un portail reprend des améliorations en mettant à jour ses packages — la page que vous écrivez est la porte du rôle et l’en-tête.

Qu’y a-t-il sur la page

Deux grilles, chacune avec Nouvelles, Ouvrir et Supprimer. Chaque modification est écrite dès que vous la sauvegardez ou la supprimez — il n’y a pas de sauvegarde au niveau de la page.

• Rôles du portail — un nom et une description, modifiés dans un panneau latéral. Ce qu’un rôle accorde n’est pas configuré ici : il est lié au nom du rôle en code au démarrage, donc ajouter un rôle le rend assignable plutôt que puissant, et le renommer le détache de ce qu’il accorde.
• Configurations de rôles — quel rôle un nouvel utilisateur inscrit est attribué, et quand — à personne, à tout le monde, ou à quiconque correspond à une règle que vous écrivez.

Règles qui déterminent qui est éligible

Une règle est une requête FetchXML sur contact. Lorsqu’une personne s’enregistre, le portail resserre la requête à ce contact et attribue le rôle si Dataverse les renvoie. Les jointures vers des tables associées sont respectées, et les colonnes, trient et top ne font aucune différence pour la réponse, donc une requête copiée d’une vue fonctionne telle quelle.

Dans React, la règle est écrite avec le constructeur de requêtes FetchXML, épinglée sur Contact avec les agrégats désactivés, sur une page à part entière pour que le constructeur ait de la place. Run montre les contacts auxquels la règle correspond aujourd’hui — la seule façon de savoir si elle sélectionne les personnes dont vous parlez.

Dans Blazor, la même colonne est modifiée en tant que texte FetchXML ; il n’existe pas encore de créateur de requêtes Blazor.

Une règle brisée échoue discrètement

Une règle vide, qui n’est pas valide en FetchXML, qui est une requête agrégée, ou qui est enracinée dans une table autre que Contact ne correspond à personne. Rien ne la signale comme une erreur — le rôle n’est tout simplement jamais attribué. L’éditeur React avertit de chacun de ces éléments au-dessus du constructeur pendant que vous écrivez la règle.

L’ajouter à votre portail

Les deux modèles de projet incluent déjà cette page à /RoleConfigurationAdmin, sous le menu Admin. Pour l’ajouter vous-même, verrouillez une page avec [AuthorizeSystemAdmin] et <SystemAdminView> — dans React — useIsSystemAdmin() et insérez le composant dans :

La page de configuration (React)

configurationUrl ouvre une configuration sur sa propre page au lieu d’un panneau latéral. Si on la laisse désactivée, le panneau est utilisé, ce qui fonctionne mais laisse peu de place au constructeur de requêtes. La page vers laquelle il pointe fournit le contexte de l’enregistrement et le bouton Enregistrer ; le formulaire lui-même est celui du PortalRoleConfigurationFormframework :

Rôles web sous autorisation renforcée

Sur un portail fonctionnant avec une autorisation améliorée, les utilisateurs se voient attribuer des rôles web Power Pages plutôt que des rôles de portail : Power Pages accorde à chaque utilisateur le rôle de sécurité Dataverse qu’il associe à chacun de leurs rôles web, et ce que ce rôle permet provient des permissions de table du site. WebRoleAdmin est l’équivalent de PortalRoleAdmin pour ce modèle, avec trois grilles : les rôles web du site, leurs permissions de table — à quelle table, quelles lignes, quelles opérations, et à quels rôles web chaque s’applique — et les règles qui transmettent les rôles web aux nouveaux utilisateurs, écrites exactement comme ci-dessus. Les règles sont intégrées à la solution Power Portals Pro Enhanced Authorization , qui nécessite l’installation de Power Pages dans l’environnement.

Les deux modèles de projet affichent la page qui s’applique : le menu Admin propose des rôles Web lorsque l’autorisation améliorée est activée et la configuration des rôles lorsqu’elle est désactivée. Votre propre navigation peut faire le même choix avec ISecurityModelInfo.IsEnhancedAuthorizationEnabledAsync() Blazor ou useAuthOptions() React, les deux répondant depuis GET /api/auth/options.

La table des permissions et les relations d’une table sont choisies à partir des métadonnées de l’environnement plutôt que tapées, car un nom mal orthographié est accepté et n’accorde rien. Les champs de relation suivent le type d’accès : Contact et Account demandent comment une ligne atteint le contact ou compte de l’utilisateur, Parent demande la permission parent et comment une ligne atteint sa table, et Custom demande un filtre FetchXML — écrit avec le constructeur de requêtes FetchXML dans React, et en texte dans Blazor. Les rôles web d’une permission sont sauvegardés avec, une nouvelle permission est incluse ; la grille modifie une permission à la fois pour cette raison.

Les changements atteignent Dataverse via Power Pages

Les rôles web et les permissions de table sont des enregistrements propres à Power Pages, donc cette page et l’application Power Pages Management modifient les mêmes données, et seul le site est SecurityOptions.DataverseSecurity.PowerPagesSiteId affiché ou modifié. Power Pages transforme les permissions de table d’un rôle web en le rôle de sécurité qu’il associe au rôle web, selon son propre calendrier : un nouveau rôle web n’accorde rien tant que ce pairage n’existe pas, et les changements de rôle et de privilège peuvent prendre une minute ou deux pour atteindre un utilisateur connecté. Une règle nommant un rôle web d’un autre site est ignorée, et le portail le journalit.

Référence API

PortalRoleConfigurationForm

WebRoleAdmin

WebRoleConfigurationForm

WebRoleForm

TablePermissionForm