2013-10-30 10 views
5

Sto cercando di capire qualcosa su Symfony e il "super amministratore".Symfony - Capire il super amministratore

Quando uso FOSUser to create a user con privilegi di amministratore di super

php app/console fos:user:create adminuser --super-admin 

vorrei in primo luogo sapere che cosa significa (dal doc)

[...] Specifica del --super- admin option contrassegnerà l'utente come un amministratore eccellente [...]

immagino significhi concedere ROLE_SUPER_ADMIN per l'utente perché non vedo alcun super amministratore campo nella tabella utente.

In secondo luogo, mentre (sempre dal doc)

Un super amministratore ha accesso a qualsiasi parte della vostra applicazione

security: 
    role_hierarchy: 
     ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH, ...] 

Perché abbiamo ancora bisogno di configurare la gerarchia di accesso per vero?

risposta

4

Guardando il codice di FOSUserBundle troverete che il CreateUserCommand se invocata con il flag --super-admin chiamerà il UserManipulator con un argomento booleano $superadmin=true.

Ora UserManipulator chiama lo UserManager che creerà un oggetto utente, chiamerà il suo metodo setSuperAdmin() e continuerà il nuovo utente in seguito.

Il metodo ha il seguente aspetto:

public function setSuperAdmin($boolean) 
{ 
    if (true === $boolean) { 
     $this->addRole(static::ROLE_SUPER_ADMIN); 
    } else { 
     $this->removeRole(static::ROLE_SUPER_ADMIN); 
    } 

    return $this; 
} 

Quindi rispondere alla tua prima domanda:

, la bandiera --super-admin provoca FOSUserBundle per creare un nuovo utente con il ruolo ROLE_SUPER_ADMIN.

È ancora necessario includere la gerarchia dei ruoli nella configurazione della sicurezza poiché il ruolo ROLE_SUPER_ADMIN non differisce sostanzialmente da altri ruoli.

E 'solo una convenzione provided by the Symfony standard edition che gli utenti con ruolo ROLE_SUPER_ADMIN non dovrebbero avere alcuna restrizione di accesso.

Se si desidera che il ROLE_SUPER_ADMIN per ignorare tutti gli elettori di sicurezza per impostazione predefinita - uno sguardo al IddqdVoter di JMSSecurityExtraBundle che implementa questo per il ruolo particolare ROLE_IDDQD. Ma questo è già stato suggerito nell'altra domanda here.

+0

Ok, capisco, ho pensato che riguardava solo gli elettori e ho dimenticato che gli elettori sono sempre chiamati. Ho anche pensato che fosse fatto come in Django, in cui i superutenti hanno automaticamente tutti i diritti. Non riesco a immaginare una situazione in cui vogliamo nascondere qualcosa ai superutenti. –

1

Definendo la gerarchia, è esplicitamente concesso il ROLE_ADMIN e ruoli ROLE_ALLOWED_TO_SWITCH (o altri ruoli personalizzati si potrebbe avere)

Se si commenta questa linea, e si tenta di accedere con il proprio utente ROLE_SUPER_ADMIN ad un'azione con un controllo ROLE_ADMIN, riceverai un errore non consentito.

ROLE_SUPER_ADMIN è solo una convenzione per il nome che dovrebbe avere il ruolo di super amministratore, ma non dispone di privilegi da parte sua, è necessario concedergli esplicitamente.

+0

Hai appena copiato la parte della convenzione della mia risposta? :) – nifr

+0

Haha, no, stavamo lavorando contemporaneamente allo stesso tempo :) Penso che sia la risposta ovvia quando capisci come funzionano i ruoli in Symfony2. Ma ho parlato della convenzione in tutta Symfony, non solo in FOSUserBundle – jmoreno

+0

Grazie per questa semplice risposta. –