Ebenen der Berechtigungsprüfung
- Benutzerinterface (UI)
In der obersten Ebene prüft das Benutzerinterface Rechte und deaktiviert beispielsweise Aktionen, die man ohnehin nicht ausführen darf.
Diese Art der Berechtigungsprüfung gilt als unsicher, weil sie vom Endanwender durch Manipulation im Browser umgangen werden kann. Projekte, die eigene Steuerelemente implementieren, müssen diese Prüfungen im Allgemeinen auch überprüfen. - Implementierung von Funktionen (serverseitig)
Wenn eine Aktion ausgeführt wird, prüft ihre Implementierung ihrerseits ein zweites Mal die Berechtigungen.
Diese Prüfung kann vom Endanwender nicht umgangen werden. Programmierungen in Projekten können und müssen diese Prüfungen aber selbst durchführen. - Prüfungen in BA
Diese Prüfungen können auch in Projekten durch Programmierung nicht umgangen werden.
Dazu gehört zum Beispiel das Prüfen der Schreib bzw. Löschrechte beim Speichern von Datensätzen oder auch der Leserechte beim Öffnen einer Maske.
Automatische Berechtigungsprüfungen
Schreibrechte
Alle modifizierenden Berechtigungen auf Datensätze werden vom Core automatisch geprüft.
Das bedeutet, dass man sich in Projekten bei der Implementierung von Funktionen (Ebene 2) im Allgemeinen nicht unbedingt um die Prüfung der Schreibrechte kümmern muss es aber im Sinne einer sinnvollen Meldung an den Benutzer tun sollte.
Allerdings ist es oft angebracht, bei den zugehörigen Aktionen vorab (Ebene 1) eine Prüfung durchzuführen, um dem Benutzer im Benutzerinterface bereits zu signalisieren, dass er etwas nicht darf.
Die Steuerelemente in BA implementieren alle sinnvollen Berechtigungsprüfungen in Ebene 1 und 2. Nur bei Erweiterungen muss man sich damit befassen.
Leserechte
BA prüft Leserechte bei API-Aufrufen im Allgemeinen nicht (im Gegensatz zu den Schreibrechten).
Ausnahmen:
- Platzhalter (PropertyResolver)
Bei der Berechnung von Werten für Platzhalter in Vorlagen erfolgt eine Prüfung der Leserechte, wenn dabei über Relationen auf andere Datensätze zugegriffen wird. Fehlen dabei irgendwelche Leserechte, so wird der Platzhalter immer leer. Dies ist erforderlich, weil sich Anwender mit Bearbeiterrechten für Vorlagen sonst Zugriff auf beliebige Felder unlesbarer Datensätze verschaffen könnten. - Ansichten
Die Ansichten prüfen die Leserechte auf die angezeigten Zeilen. Sie prüfen nicht, wenn man über Relations-Spalten auf fremde Datensätze zugreift. Es obliegt dem Konfigurator auf diese Weise keine sensiblen Daten zu exponieren. - API-Funktionen für Leserechte
Natürlich gibt es API-Funktionen, die nur oder auch für Leserechte vorgesehen sind. Aber nur bei Funktionen, wo das bereits aus dem Funktions- oder Parameternamen hervor geht, findet eine solche Prüfung statt.
Sonstige Rechte
Alle sonstigen Rechte werden von BA in Ebene 2, also der Implementierung der jeweiligen Funktionen, geprüft. Wenn man eigene Funktionen in Projekten implementiert, muss man sich auch um diese Prüfungen kümmern.