Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Beispiel 5: UI-Filterung mit verifizierten Berechtigungen und Cedar
<a name="avp-ui-filtering-examples"></a>

Sie können Verified Permissions auch verwenden, um die RBAC-Filterung von UI-Elementen auf der Grundlage autorisierter Aktionen zu implementieren. Dies ist äußerst nützlich für Anwendungen mit kontextsensitiven Benutzeroberflächenelementen, die im Fall einer mehrinstanzenfähigen SaaS-Anwendung bestimmten Benutzern oder Mandanten zugeordnet sein könnten.

Im folgenden Beispiel dürfen `Users` von ihnen `Role` `viewer` keine Updates durchführen. Für diese Benutzer sollte die Benutzeroberfläche keine Aktualisierungsschaltflächen rendern.

![Beispiel für UI-Filterung mit Amazon Verified Permissions und Cedar](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-5.png)


In diesem Beispiel hat eine einseitige Webanwendung vier Schaltflächen. Welche Schaltflächen sichtbar sind, hängt `Role` von dem Benutzer ab, der gerade bei der Anwendung angemeldet ist. Beim Rendern der Benutzeroberfläche durch die einseitige Webanwendung werden verifizierte Berechtigungen abgefragt, um zu ermitteln, zu welchen Aktionen der Benutzer berechtigt ist, und generiert dann die Schaltflächen auf der Grundlage der Autorisierungsentscheidung.

Die folgende Richtlinie legt fest, dass der Typ `Role` mit dem Wert sowohl Benutzer als auch Daten anzeigen `viewer` kann. Eine `ALLOW` Autorisierungsentscheidung für diese Richtlinie erfordert eine `viewData` `viewUsers` OR-Aktion und erfordert außerdem, dass dem Typ `Data` oder eine Ressource zugeordnet wird`Users`. Eine `ALLOW` Entscheidung ermöglicht es der Benutzeroberfläche, zwei Schaltflächen zu rendern: `viewDataButton` und`viewUsersButton`.

```
permit (
    principal in GuiAPP::Role::"viewer",
    action in [GuiAPP::Action::"viewData", GuiAPP::Action::"viewUsers"],
    resource 
)
when {
   resource in [GuiAPP::Type::"Data", GuiAPP::Type::"Users"]
};
```

Die folgende Richtlinie legt fest, dass der Typ `Role` mit dem Wert von nur Daten anzeigen `viewerDataOnly` kann. Eine `ALLOW` Autorisierungsentscheidung für diese Richtlinie erfordert eine `viewData` Aktion und erfordert außerdem, dass dem Typ eine Ressource zugeordnet wird`Data`. Eine `ALLOW` Entscheidung ermöglicht es der Benutzeroberfläche, die Schaltfläche zu rendern`viewDataButton`.

```
permit (
    principal in GuiApp::Role::"viewerDataOnly",
    action in [GuiApp::Action::"viewData"],
    resource in [GuiApp::Type::"Data"] 
);
```

Die folgende Richtlinie legt fest, dass der Typ `Role` mit dem Wert Daten und Benutzer bearbeiten und anzeigen `admin` kann. Eine `ALLOW` Autorisierungsentscheidung für diese Richtlinie erfordert die Aktion `updateData` `updateUsers``viewUsers`, `viewData,` oder und außerdem muss dem Typ `Data` oder eine Ressource zugeordnet werden`Users`. Eine `ALLOW` Entscheidung ermöglicht es der Benutzeroberfläche, alle vier Schaltflächen zu rendern: `updateDataButton``updateUsersButton`,`viewDataButton`, und`viewUsersButton`.

```
permit (
    principal in GuiApp::Role::"admin",
    action in [
        GuiApp::Action::"updateData",
        GuiApp::Action::"updateUsers",
        GuiApp::Action::"viewData", 
        GuiApp::Action::"viewUsers"
       ],
    resource 
)
when {
   resource in [GuiApp::Type::"Data", GuiApp::Type::"Users"]
};
```