Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Progettare le rotte con autenticazione

Scopriamo come configurare Symfony in modo che tutte le rotte di un sito risultino inaccessibili da un utente anonimo eccetto la rotta dedicata al login
Scopriamo come configurare Symfony in modo che tutte le rotte di un sito risultino inaccessibili da un utente anonimo eccetto la rotta dedicata al login
Link copiato negli appunti

Ora che abbiamo una pagina di login possiamo iniziare a bloccare l'accesso alle pagine del nostro sito qualora l'utente non fosse loggato. In questa fase possiamo configurare Symfony affinché tutte le rotte del sito risultino inaccessibili da un utente anonimo eccetto la rotta di login. Più avanti potremo aver bisogno di abilitare altre pagine agli utenti non loggati ma lo faremo solo quando sarà nacessario.

Per fare in modo di essere reindirizzati alla pagina di login quando non si è autenticati abbiamo bisogno di intervenire all'interno del file app/config/packages/security.yaml. Nella parte finale del file troveremo una sezione access_control che ci permette di definire le regole di accesso alle singole rotte (o intere aree del sito) in base a delle regole di match.

Per ogni richiesta in ingresso che arriva Symfony decide quale delle regole applicare in base a:

  • URI della richiesta.
  • Indirizzo IP del client.
  • Hostname.
  • metodo HTTP della richiesta.

Le regole sono basate su delle espressioni regolari che identificano il path delle le rotte. Per fare un esempio:

access_control:
    - { path: ^/admin, roles: ROLE_ADMIN }
    - { path: ^/profile, roles: ROLE_USER }

Tali regole garantiscono l'accesso a tutte le rotte che iniziano per /admin ai soli utenti loggati che hanno il ruolo ROLE_ADMIN, la seconda invece garantisce l'accesso a tutte le rotte che iniziano per /profile a tutti gli utenti che hanno il ruolo ROLE_USER. Approfondiremo a breve il concetto di ruolo, per adesso ci basta sapere che possiamo assegnare uno o più ruoli ad utente (o più in generale a un client che accede all'applicazione).

L'ordine delle regole non è casuale. Il RequestMatcher di Symfony si ferma alla prima regola che soddisfa la richiesta.

La nostra applicazione, in questa fase, necessita di un solo ruolo (ROLE_USER andrà benissimo) e possiamo impostare, come in precedenza, l'access control in modo da richiedere quel ruolo per tutte le rotte tranne il login:

access_control:
 - { path: ^/login$, roles: IS_AUTHENTICATED_ANONYMOUSLY }
 - { path: ^/, roles: ROLE_USER }

Le nostre due regole di accesso ci dicono che:

  1. l'accesso alla rotta specifica /login (quindi, ad esempio, /login-123 o /login/123 non rispettano questa regola) è concesso agli utenti non loggati. Il significato di IS_AUTHENTICATED_ANONYMOUSLY è spiegato nella sezione Ruoli in coda alla lezione.
  2. Qualsiasi altra richiesta richiede che l'utente abbia il ruolo ROLE_USER.

Il modello User di base che stiamo utilizzando in questa fase di default non ha quel ruolo ma glielo abbiamo assegnato nelle precedenti lezioni definendo l'utente ryan. Se guardiamo infatti nella sezione providers.backend_users.memory.users.ryan all'interno dello stesso file noteremo che è presente un array roles con lo specifico ruolo.

Non dobbiamo fare altro, possiamo a questo punto provare il nostro codice e verificare che l'home page sia accessibile solo dopo aver effettuato il login e che le pagine di login e logout funzionino correttamente.

Il codice della lezione è disponibile con il tag restrict-access all'interno del repository.

Ruoli

I ruoli in Symfony sono semplicemente delle stringhe che iniziano per ROLE_ e che possono essere assegnate alle varie tipologie di utenti/client che utilizzano l'applicazione.

I ruoli vengono utilizzati per garantire i permessi di accesso a specifiche aree dell'applicazione. Si possono assegnare ruoli multipli a un utente e, soprattutto, si può configurare Symfony affinché un ruolo erediti i permessi di un altro ruolo attraverso la Role Hierarchy. Tali gerarchie possono essere configurate all'interno del file security.yaml come nell'esempio seguente:

role_hierarchy:
	ROLE_ADMIN:       ROLE_USER
	ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_ALLOWED_TO_SWITCH]

ROLE_ALLOWED_TO_SWITCH è un ruolo particolare che consente a un utente con quel permesso di impersonare un qualsiasi altro utente dell'applicazione. Ci sono poi altri attributi che Symfony attribuisce a un utente che però possono agire all'occorrenza come ruoli. Uno lo abbiamo appena visto mentre definivamo le regole di accesso. Alcuni di questi sono:

Attributo Descrizione
IS_AUTHENTICATED_ANONYMOUSLY Viene assegnato a tutti gli utenti, anche quelli non ancora autenticati. Questo genere di attributi viene impiegato quando non abbiamo la necessità di verificare il tipo di ruolo ma ci interessa solo sapere se un utente ha effettuato il login o meno.
IS_AUTHENTICATED_REMEMBERED Tutti gli utenti loggati anche se il login non è stato effettuato ora ma in passato avendo selezionato l'opzione Remind me.
IS_AUTHENTICATED_FULLY E' un livello di autenticazione più forte perché è vero solo se l'accesso non è stato effettuato in passato.

Ti consigliamo anche