Rollenkonfigurationsadministrator

PortalRoleAdmin ist die Administrationsseite für Portalrollen: Welche Rollen das Portal hat und welche davon einem neu registrierten Benutzer zugewiesen werden. Sie wird mit dem Framework auf beiden Stacks ausgeliefert, sodass ein Portal Verbesserungen daran erkennt, indem es seine Pakete aktualisiert – die Seite, die du schreibst, ist das Rollengatter und die Überschrift.

Was steht auf der Seite

Zwei Raster, jeweils mit Neu, Öffnen und Löschen. Jede Änderung wird geschrieben, sobald man sie speichert oder löscht – es gibt kein Seitenebene-Speicher.

• Portalrollen — ein Name und eine Beschreibung, die in einem Seitenpanel bearbeitet werden. Was eine Rolle gewährt , ist hier nicht konfiguriert: Sie ist beim Start im Code an den Namen der Rolle gebunden, sodass das Hinzufügen einer Rolle sie zuweisend statt mächtig macht, und eine Umbenennung trennt sie von dem, was sie gewährt.
• Rollenkonfigurationen — Welche Rolle ein neu registrierter Nutzer erhält und wann – niemandem, allen oder demjenigen, der einer Regel entspricht, die du schreibst.

Regeln, die entscheiden, wer sich qualifiziert

Eine Regel ist eine FetchXML-Abfrage über contact. Wenn sich jemand registriert, grenzt das Portal die Abfrage auf diesen Kontakt ein und weist die Rolle zu, wenn Dataverse sie zurückgibt. Joins zu verwandten Tabellen werden anerkannt, und Spalten, sortieren und top machen keinen Unterschied an der Antwort, sodass eine aus einer Ansicht kopierte Abfrage so funktioniert, wie sie ist.

In React wird die Regel mit dem FetchXML Query Builder geschrieben, der mit deaktivierten Aggregaten an Contact gepinnt ist, auf einer eigenen Seite, damit der Builder Platz hat. Run zeigt die Kontakte an, mit denen die Regel heute übereinstimmt – die einzige Möglichkeit herauszufinden, ob die von Ihnen gemeinten Personen ausgewählt werden.

In Blazor wird dieselbe Spalte als FetchXML-Text bearbeitet; es gibt noch keinen Blazor-Abfragegenerator.

Eine gebrochene Regel scheitert still und leise

Eine Regel, die leer ist, nicht gültig ist, eine Aggregate-Abfrage ist oder in einer anderen Tabelle als Contact verwurzelt ist, passt zu niemandem. Nichts meldet es als Fehler – die Rolle wird einfach nie zugewiesen. Der React-Editor warnt vor jedem dieser Regeln über dem Builder, während Sie die Regel schreiben.

Hinzufügen zu deinem Portal

Beide Projektvorlagen enthalten bereits diese Seite unter /RoleConfigurationAdmin, unter dem Admin-Menü. Um es selbst hinzuzufügen, gatet eine Seite mit [AuthorizeSystemAdmin] und <SystemAdminView> — in React useIsSystemAdmin() — und fügt die Komponente ein:

Die Konfigurationsseite (React)

configurationUrl öffnet eine Konfiguration auf einer eigenen Seite statt in einem Seitenpanel. Lässt man sie aus, wird das Panel verwendet, was funktioniert, aber dem Abfrage-Builder wenig Spielraum lässt. Die Seite, auf die es zeigt, liefert den Datensatzkontext und den Speichern-Button; das Formular selbst ist das PortalRoleConfigurationFormdes Frameworks:

Webrollen unter erweiterter Autorisierung

Auf einem Portal mit erweiterter Autorisierung erhalten Nutzer Power Pages-Webrollen statt Portalrollen: Power Pages gewährt jedem Benutzer die Dataverse-Sicherheitsrolle, die es mit jeder seiner Webrollen koppelt, und was diese Rolle ermöglicht, stammt aus den Tabellenberechtigungen der Seite. WebRoleAdmin ist das Gegenstück zu PortalRoleAdmin für dieses Modell mit drei Rastern: den Webrollen der Website, ihren Tabellenberechtigungen – welche Tabelle, welche Zeilen, welche Operationen und welche Webrollen jeweils gelten – sowie die Regeln, die Webrollen an neue Nutzer übergeben, genau wie oben geschrieben. Die Regeln befinden sich in der Power Portals Pro Enhanced Authorization-Lösung , die Power Pages in der Umgebung installieren muss.

Beide Projektvorlagen zeigen die passende Seite an: Das Admin-Menü bietet Web-Rollen an, wenn erweiterte Autorisierung aktiviert ist, und Rollenkonfiguration, wenn sie ausgeschaltet ist. Deine eigene Navigation kann dieselbe Wahl mit ISecurityModelInfo.IsEnhancedAuthorizationEnabledAsync() in Blazor oder useAuthOptions() in React treffen, beide werden von GET /api/auth/options.

Die Tabellenberechtigung und die Beziehungen einer Tabellenberechtigung werden aus den Metadaten der Umgebung ausgewählt und nicht getippt, da ein falsch geschriebener Name akzeptiert wird und nichts gewährt. Die Beziehungsfelder folgen dem Zugriffstyp: Contact und Account fragen, wie eine Zeile den Kontakt oder das Konto des Benutzers erreicht, Parent fragt nach der Elternberechtigung und wie eine Zeile ihre Tabelle erreicht, und Custom fragt nach einem FetchXML-Filter – geschrieben mit dem FetchXML-Abfragegenerator in React und als Text in Blazor. Die Webrollen einer Berechtigung werden mit ihr gespeichert, eine neue Berechtigung wird hinzugefügt; das Raster bearbeitet aus diesem Grund eine Berechtigung nach dem anderen.

Änderungen erreichen Dataverse über Power Pages

Webrollen und Tabellenberechtigungen sind die eigenen Einträge von Power Pages, daher bearbeiten diese Seite und die Power Pages Management-App dieselben Daten, und nur die Seite wird SecurityOptions.DataverseSecurity.PowerPagesSiteId angezeigt oder geändert. Power Pages wandelt die Tabellenberechtigungen einer Webrolle in die Sicherheitsrolle um, die sie mit der Webrolle koppelt, nach eigenem Zeitplan: Eine neue Webrolle gewährt nichts, bis diese Paarung existiert, und Änderungen bei Rollen und Privilegien können ein bis zwei Minuten dauern, um einen angemeldeten Benutzer zu erreichen. Eine Regel, die eine Webrolle einer anderen Seite benennt, wird übersprungen und das Portal protokolliert sie.

API-Referenz

PortalRoleConfigurationForm

WebRoleAdmin

WebRoleConfigurationForm

WebRoleForm

TablePermissionForm