PHP MVC / PAC - Posizionamento delle verifiche di accesso / amministrazione

Question

PHP MVC / PAC - Posizionamento delle verifiche di accesso / amministrazione

#1 da (2 voti)
#2 da (2 voti)
#3 da (0 voti)

8

Ho configurato una struttura simile a MVC / PAC per un'applicazione web (incerto se si adatta completamente a questi schemi di progettazione). In breve è:

Routing in index.php , che seleziona il controller e il metodo utilizzando l'URL http://example.com/controller/method/<params>
Il metodo del controllore richiede dati da 'model (s)' e li assegna a una vista.

Ora mi chiedo quale sia il posto migliore per un controllo registrato. Diciamo che ho una pagina a http://example.com/controller-one/method-one/ che richiede che l'utente sia un amministratore registrato; Dove posso verificare se l'utente è effettivamente? Nel routing, nel controller o nel modello?

Si noti che un controller e / o un modello potrebbero contenere metodi con diversi "diritti".

Nota: esiste un modello chiamato Authentication che contiene un metodo chiamato isLogged() che restituisce vero o falso in base al fatto che l'utente abbia effettuato l'accesso e un altro metodo chiamato IsLoggedAdmin() che restituisce vero o falso in base a se l'utente è un amministratore registrato.

Quindi ...: qual è la posizione migliore per chiamare il metodo isLogged o isLoggedAdmin . Nel controllo e / o nel metodo (i) del controllore o nel contrato e / o nel / i metodo / i del modello?

web-development web-applications mvc mvp pac

posta kgongonowdoe 03.05.2016 - 10:08

fonte

3 risposte

Leggi altre domande sui tag web-development web-applications mvc mvp pac

Null Object Pattern e Input validation - copia l'implementazione reale o accetta tutto in silenzio? Come strutturare un'applicazione Go, progettata in base all'architettura pulita

score 2 · Answer 1

Vengo dal mondo Java, ma le cose sono abbastanza simili, quindi ecco alcuni suggerimenti sul controllo dei diritti secondo me.

Se il tuo diritto è un diritto come "avere il diritto di eseguire l'azione X". Quindi dovresti controllare prima del routing e nel livello di servizio.

Il controllo nel livello di servizio è per essere sicuro che ogni volta che chiami quel servizio, avrai un controllo detto.
Il controllo molto tempestivo è per non avere un po 'del tuo codice (recupero dei dati, ...) che può accadere prima di controllare la destra. Mi è stato detto che è stato fatto anche per sostenere in modo più efficiente gli attacchi DDOS. Prima si rifiuta una richiesta, meglio è.

Se hai il diritto di "avere il diritto di eseguire azioni X su Y", suppongo che tu possa averlo solo nel livello di servizio, come possibile in precedenza. Tuttavia, se il tuo framework fornisce servizi per eseguire ciò durante l'esecuzione del routing, fai questo, tuttavia preferisco sinceramente il controllo del servizio, poiché la funzione del servizio può essere utilizzata da vari punti.

Potresti perfettamente avere due set di Rôles:

Uno simile: ADMIN / GUEST / USER: utilizzato per il controllo rapido del routing, memorizzato nella sessione utente
Diritti: utilizzati dal livello di servizio, memorizzati nel database o in qualsiasi archivio persistente.

score 2 · Answer 2

L'autenticazione dovrebbe avvenire dopo il routing ma prima di chiamare il controller oi suoi metodi.

A quel punto sai quale rotta è stata richiesta e puoi controllare se l'utente ha i privilegi per eseguire una determinata azione (controller di chiamata).

Ciò consente non solo di separare le preoccupazioni, ma anche di decidere come gestire le richieste non autorizzate prima che colpiscano i controllori, ad es. reindirizzarli verso l'altro controller internamente con una risposta 403.

L'autenticazione / autorizzazione avviene nello strato superiore rispetto ai modelli. Se dipendono da istanze utente - passi un'istanza già autenticata / autorizzata. Inoltre, quando i requisiti cambiano e gli altri ruoli sono autorizzati a richiamare metodi precedentemente vietati, modifichi solo gli ACL e non i modelli.

Il framework Symfony aveva una bella descrizione di come funzionavano, è ancora disponibile per la v.2: link

score 0 · Answer 3

Un tentativo di semplificare e chiarire.

Passaggio 1 : determina se il percorso esiste. Se il percorso non esiste, ricorda di inviare un codice di risposta HTTP 404 (Not Found) in aggiunta a qualsiasi altra cosa tu faccia.

Passaggio 2 : se la rotta esiste, stabilisci se richiede l'autenticazione (definizione dell'identità).

Passaggio 3 : se è richiesta l'autenticazione, controlla lo stato di autenticazione (l'utente ha effettuato l'accesso?), prima di creare un'istanza di Controller .

Passaggio 4a : se l'utente / visitatore è non collegato, reindirizza a LoginController con un codice di risposta HTTP 303 (See Other) . Se l'accesso non riesce, ricorda di inviare un codice di risposta HTTP 401 (Unauthorized) .

Passaggio 4b : se l'utente è già autenticato (connesso), controlla se ha i diritti necessari per accedere alla risorsa e all'azione / metodo in questione (prima di istanziare un Controller ). Se ha diritti insufficienti, ricorda di inviare un codice di risposta HTTP 402 (Forbidden) .

Certo, si determina dove finisce qualcuno dopo l'accesso, un errore o l'impossibilità di accedere al contenuto protetto. Questa non è la parte importante qui.

Passaggio 5 : ora, dopo che il Controller è stato istanziato, assicurati che l'utente sia ancora connesso e verifica l'autorizzazione (diritti) per intraprendere un'azione specifica .

Sommario

In effetti, il primo controllo dell'autenticazione e dell'autorizzazione riguarda la natura della richiesta HTTP stessa. Se la richiesta è autorizzata a fare in modo che il sistema faccia un sacco di lavoro per arrivare all'azione / metodo richiesto?

Il controllo secondo dell'autenticazione e dell'autorizzazione riguarda l'accertamento che lo stato della richiesta sia ancora valido in un dominio del tempo (sebbene la finestra temporale possa essere molto piccola, in effetti). Gli account vengono sospesi, abbassati di livello e forzati per tutto il tempo. Solo perché la richiesta iniziale è buona, non significa che sia ancora buona, 005 secondi dopo.