Ich verwende SonataAdminBundle in Symfony 3. Da ich Symfony 3 verwende, kann ich SonataUserBundle immer noch nicht verwenden. Also verwende ich SonataAdminBundle nur mit FOSUserBundle.
Nun versuche ich, bestimmte Routen pro Rolle zu verbergen. Zum Beispiel habe ich nur drei Rollen:
Super Admin hat alle Rollen, die Admin hat, Admin hat alle die dritte, und die dritte hat offensichtlich ROLE_USER. Super Admin sollte in der Lage sein, neue Benutzer zu erstellen und ihm eine Rolle zuzuweisen. Der Super Admin sollte auch in der Lage sein, die Passwörter eines Benutzers zu ändern. Die Benutzer sollten die Kennwörter ihrer eigenen Konten ändern können. Und schließlich, andere Rollen, die Super Admin sollte nicht in der Lage sein, ihre eigenen Rollen zu ändern und neue Benutzer zu erstellen.
Wie kann ich dies ohne SonataUserBundle erreichen? Für das Entfernen von Routen habe ich etwas wie folgt versucht:
%Vor%Aber ich denke, es gibt eine bessere Lösung. Ich bin mir der offiziellen Dokumentation über Sicherheit durchaus bewusst, aber ich bin es verwirrt das, bedeutet das, dass ich jede einzelne Rolle für alle verschiedenen Admins in meiner %code% Datei fest codieren muss? Funktioniert das sogar ohne SonataUserBundle? Ich möchte keine zusätzlichen Datenbanktabellen für ACL hinzufügen.
Kann jemand bitte helfen und / oder ein gutes Beispiel geben? Ich werde es wirklich sehr schätzen.
Dies ist, was ich bisher nur habe, dass Benutzer neue Benutzer nicht erstellen können und Benutzer nicht bearbeiten und löschen können. Das ist einfach lächerlich, jede einzelne Rolle zu spezifizieren, nur um die 2 oder 3 zu entfernen, die ich nicht will:
%Vor%Hat jemand einen besseren Weg? Bitte?
Antwort: wir müssen dasselbe tun wie %code% . (Aber lassen Sie uns ein wenig vereinfachen)
Die Tür: Platz im Haus, wo der Zugang eingeschränkt ist - %code% :
%Vor%Der Schlüssel: Berechtigung für den Zugriff auf eine eingeschränkte Tür erteilt - %code% :
%Vor%Der Hauptschlüssel: Ein Schlüssel, der mehrere Türen öffnen kann:
%Vor%Nach dieser Analogie hat %code% bereits die Türen zur Beschränkung des Zugriffs auf jede Standardaktion erstellt ( zB %code% Aktion ) über eine verwaltete Entität.
Unsere Aufgabe besteht also darin, die Schlüssel den Benutzern "nur" zuzuweisen (es sei denn, Sie müssen Ihre eigenen Türen erstellen). Es gibt viele Möglichkeiten, dies zu archivieren (es hängt davon ab, was zu tun ist) ).
Hinweis: Wenn Sie keine Rollenhierarchie haben, haben Sie nur einzelne Schlüssel (d. h. Sie haben keine Hauptschlüssel), wodurch die Rollen (Schlüssel) weniger flexibel zugewiesen werden können.
Nun verwendet %code% eine bestimmte Methode, um die Schlüssel in einem Kontext der admin-Klasse zu überprüfen, indem Sie einfach folgendes tun: %code% , weil er seine eigene %code% -Funktion hat (wobei %code% der ist aktionsname), aber wirklich, was es tut, ist den Namen der Rolle (mit dem aktuellen Admin-Code) zu erstellen, bevor Sie es überprüfen, so dass er dies schließlich überprüfen: %code% -dieser Schlüssel ist es, was wir brauchen "geben" an den Benutzer.
In einem Controller-Kontext:
%Vor%Als Nächstes können Sie alles damit machen (z. B. einen benutzerdefinierten Formulartyp zum Verwalten der Benutzerrolleneigenschaft erstellen). Sie könnten sortieren, gruppieren diese Rollen, um dem Benutzer diese Liste auf die einfachste Weise zu zeigen.
Hier oben können wir Rollen zuweisen und arbeiten, ohne auch %code% zu verwenden.
Weitere Details Ссылка
Sie können einen benutzerdefinierten User-Permission-Voter für Ihre User-Entity definieren, siehe hier .
> %Vor%Dann erstellen Sie den Service
%Vor%Seien Sie vorsichtig mit der Strategie Zugriffsentscheidung , I funktioniert möglicherweise nicht abhängig von Ihrer Konfiguration, wenn sie in %code% oder %code%
definiert istSie können auch eine direkte Verknüpfung / Route zur eigenen Bearbeitungsseite des Benutzers hinzufügen, wenn Sie nicht jedem Benutzer Zugriff auf die Benutzerliste gewähren möchten.
BEARBEITEN
Um die Benutzerrollenbearbeitung einzuschränken, können Sie einfach die Funktion %code% bearbeiten:
, damit ein Benutzer seine eigene Rolle nicht bearbeiten kann %Vor%Offensichtlich prüft die Symfony-Formularkomponente für Sie, dass kein anderes Feld hinzugefügt wird.