Als Teil welcher Ebene sollten Berechtigungen in MVC angewendet werden?

Question

Auf welcher Ebene (Model, View, Controller) von MVC sollte die Berechtigungslogik behandelt werden?

Lassen Sie mich das ein wenig klären. Offensichtlich muss die Benutzeroberfläche (Ansicht und Controller) Zugriff auf Berechtigungen zum Anzeigen/Verbergen von Komponenten und zum Behandeln des Szenarios mit verweigerter Berechtigung haben. Es scheint auch offensichtlich, dass die Berechtigungen von der Model-Ebene in der Datenbank beibehalten werden sollten.

Aber was ist mit "komplexen" Berechtigungsregeln wie diesem?
In einem Wiki/CMS-System, das ich entwickle, hat jeder Benutzer eine Reihe von Berechtigungen pro Seite (Anzeigen, Bearbeiten, Umbenennen usw.). Bei vorhandenen Seiten werden diese Berechtigungen von der Datenbank abgerufen. Für eine neue Seite wird angenommen, dass der Benutzer alle möglichen Berechtigungen hat (während er sie erstellt/bearbeitet).

Ein anderes Beispiel wäre die Liste der Seiten:
Der aktuelle Benutzer sollte nur in der Seitenliste Seiten sehen können, für die er eine Anzeigeberechtigung hat.

Soll der Controller diese Logik verarbeiten? Oder sollte der Controller nur für das Aufrufen einer GetPermissions() -Methode (oder GetPageList) verantwortlich sein und die gesamte Logik zum Auffüllen des Modells im Modell behandelt werden?

Answer 1

Die Steuerung des Zugriffs auf Problemdomäneneinheiten gehört in das Modell. Es ist der geeignete Ort, weil (1) die Zugriffssteuerung für Domänenentitäten eng mit den Entitäten selbst verbunden ist und (2) an einer Stelle sichergestellt ist, dass keine zwei Controller unterschiedliche Zugriffsrichtlinien für dieselben Objekte zulassen.

Die folgenden Faktoren fügen Sie einige Verwirrung:

1. Authentifizierung auf Controller-Ebene tritt
2. Einige Tools und Demos für die Anwendung Zugriffskontrolle leicht zugänglich sind - an der Controller-Schicht, z.B. this, this oder that.

Es gehört immer noch zu dem Modell.

Answer 2

Das Modell sollte die Informationen zu den zulässigen/verweigerten Berechtigungen für den angemeldeten Benutzer enthalten. Dann sollte der Controller Aktionen entsprechend dem Modell zulassen/blockieren. Gleichzeitig sollte die Ansicht nur Links anzeigen, die den Aktionen entsprechen, die der Benutzer ausführen darf. Die Ansicht wird wissen, ob sie eine bestimmte Verknüpfung (oder noch einmal) mit dem Modell malen soll oder nicht.

Sie müssen die defensive Programmierung verwenden: Wenn Sie den Zugriff auf die Aktion auf dem Controller nicht kontrollieren, können Sie für einen bestimmten Benutzer keinen Link erstellen, aber dieser Benutzer kann weiterhin eine Aktion ausführen. Auf der anderen Seite ärgert einen Link einer Aktion, die abstürzen wird (wenn nur Berechtigungen auf Controller überprüft werden) Ihre Benutzer.