Benötigen Sie wirklich eine Vertrauens- oder Laravel-Erlaubnis, um Ihre Autorisierung umzusetzen?

„Also ... ich brauche eine einfache Genehmigung. Eine Art Administratorrolle und vielleicht die Rolle des Editors / Moderators. Jetzt google es. Oh! Es gibt bereits fertige Pakete für Laravel! Zizaco / Vertrauen , Spatie / Laravel-Erlaubnis und andere! Lass uns welche auswählen! “

So passiert alles. Anschließend fügt die Paketmigration der Datenbank 5 Beschriftungen zum Speichern von Rollen, Berechtigungen und deren Beziehungen hinzu. In diesen Tabellen werden alle Autorisierungsregeln gespeichert, z. B. die Rollen "Admin" und "Editor", die "Beiträge bearbeiten " können. In der Regel verfügt ein Projekt über viele Kopien der Datenbank. Kopien von Entwicklern, Testbasis (en) und Produktion. Infolgedessen müssen alle diese Autorisierungsregeln zwischen Datenbanken synchronisiert werden.

Ich habe einige Projekte getroffen, bei denen es eine Hauptkopie der Regeln in der Produktionsdatenbank gab und der Rest alles von dort kopierte.

Die Idee, die Seeder-Klasse ( Beispiel ) zu verwenden, ist viel besser. Du musst nur rennen

php artisan db:seed AuthSeeder

und Sie haben die neueste Version der Regeln in der Datenbank. Somit wird diese Sämaschine zu einer Art Single Source Of Truth. Gut, aber es gibt immer noch viele Unannehmlichkeiten bei diesem Ansatz:

• Seeder sollte intelligent genug sein, um nicht nur Rollen und Berechtigungen sowie die Verbindungen zwischen ihnen zu erstellen, sondern auch alte Versionen zu synchronisieren. Das heißt, Entfernen oder erstellen Sie bei Bedarf Verknüpfungen zwischen Rollen und Berechtigungen.
• Regeln werden in der Datenbank gespeichert und müssen ständig synchronisiert werden. Jede Änderung der Anforderung des Formulars "Redakteure sollten Beiträge nicht mehr bearbeiten, sondern nur noch veröffentlichen" führt zu einer Änderung des Seeders, einer Synchronisierung der Codebasis durch einen Git oder etwas anderem und "VERGESSEN SIE NICHT, AuthSeeder zu starten!"
• Autorisierungsregeln können komplex sein. Beispielsweise kann eine Publikation nicht nur von Redakteuren oder Administratoren, sondern auch vom Autor dieser Publikation bearbeitet werden. Daher anstelle einer einfachen Middleware:

 ['middleware' => ['permission:edit posts']] 

Entwickler sollten die Standardautorisierung für Laravel verwenden:

 class PostPolicy { public function edit(User $user, Post $post) { return $user->id == $post->owner_id || $user->hasPermissionTo('edit posts'); } } 

Vielleicht ist der einfachste Weg nicht der beste?

Es sieht einfach aus: Legen Sie das Paket ab, führen Sie die fertige Migration aus und los geht's. Unter dem Gesichtspunkt der langfristigen Projektunterstützung ist dies nicht die beste Wahl.

Versuchen wir zu analysieren, welche Projekte normalerweise benötigt werden. Einfaches Rollenspielsystem. Fast immer eine Rolle pro Benutzer. Administrator Na ja, vielleicht ein anderer Redakteur oder Moderator. Und diese Rollen haben einige Berechtigungen. Gehen wir den direktesten Weg! Fügen Sie der Benutzertabelle ein neues Feld hinzu! is_admin oder Rolle . Dann ein paar Helfer zur User- Klasse:

 class User { public function isAdmin(): bool {...} public function isEditor(): bool {...} } 

Jetzt permishen. Laravel bietet zwei grundlegende Methoden zur Beschreibung: Gates und Richtlinien . Ich werde Gates verwenden (es gibt immer noch einen kleinen Trick mit einer Funktion in einer Variablen, aber für Liebhaber der funktionalen Programmierung ist dies überhaupt kein Trick):

  $isAdmin = function (User $user) { return $user->isAdmin(); } $isEditorOrAdmin = function (User $user) { return $user->isAdmin() || $user->isEditor(); } Gate::define('foo-permission', $isAdmin); Gate::define('bar-permission', $isAdmin); Gate::define('editor-permission', $isEditorOrAdmin); // Complex permission Gate::define('edit-post', function(User $user, Post $post) { return $user->id == $post->owner_id || $user->isAdmin(); }); 

Wenn das Projekt mehrere Rollen pro Benutzer benötigt, fügen Sie einfach die Tabelle user_roles hinzu und ändern Sie die Helfer der Benutzerklasse . Der Inhalt der Seeder-Klasse für * Trust-Pakete und dieser codebasierten Berechtigung ist nahezu identisch! Die Regeln werden jetzt einfach im Code gespeichert und müssen nicht mehr ständig in den Datenbanken synchronisiert werden.

Ich möchte nicht sagen, dass diese Pakete nutzlos sind. Dieser Ansatz ist sehr nützlich in Projekten mit einem komplexen Berechtigungssystem, in denen der Client später selbst Rollen konfigurieren möchte. Es gibt auch Projekte mit dynamischen Berechtigungen. Beispiel: Forum mit Unterforen. Jedes Unterforum kann seine eigenen Moderatoren haben. Jeder Moderator verfügt über vom Administrator in diesem Unterforum festgelegte Rechte. Ein weiteres Beispiel ist das Telegramm und seine Gruppen. Da ist das gleiche. Solche Projekte brauchen wirklich ein komplexes, in der Datenbank gespeichertes Autorisierungssystem mit all seinen Problemen. Aber die meisten anderen nicht.

Die Situation mit Paketen für Laravel ähnelt der Situation mit Komponenten für Delphi (alte Leute erinnern sich). Sie legen die Pakete ohne zu zögern - wirklich gebraucht oder nicht.

Also müsste ich in meinem Projekt hier $ a + $ b berechnen. Gibt es ein Laravel-Summenpaket?

PS Ich entschuldige mich für die Berechtigungen, habe aber keine gute genaue Übersetzung gefunden.