In circostanze normali, quando gestiamo i diritti di accesso, salviamo le informazioni di base dell'utente dopo il corretto accesso nella sessione, e le otteniamo ogni volta che l'utente richiede dati di pagina o interfaccia in futuro
Sessione per vedere e confrontare se è connesso e se può accedere alla pagina corrente.
Il principio di Session è generare un SessionID lato server corrispondente ai dati utente memorizzati, e l'ID di sessione è memorizzato in un cookie, e il client lo porterà con sé ogni volta che viene richiesto
Cookie, il server trova i dati memorizzati lato server in base all'ID della sessione nel cookie.
FormsAuthentication è fornito da Microsoft affinché noi sviluppatori lo utilizziamo per l'autenticazione. Attraverso questa autenticazione, possiamo memorizzare il nome utente e alcuni dati utente nei cookie,
L'autenticazione di base di identità e ruolo può essere facilmente raggiunta tramite impostazioni di condizione di base.
L'effetto da ottenere qui è implementare un controllo di accesso basato sui ruoli utilizzando l'Authorize fornito dal sistema senza usare l'appartenenza.
1. Creare un ticket
Dopo che l'utente effettua l'accesso, l'ID dell'utente e il ruolo corrispondente (per più ruoli, separati) vengono memorizzati nel ticket.
Cripta il ticket con FormsAuthentication.Encrypt.
Memorizza il ticket criptato nel cookie Response (il client js non deve leggere questo cookie, quindi è meglio impostare HttpOnly=True per evitare che gli attacchi del browser rubino e falsifichino cookie). In questo modo, potrai leggerlo dal cookie Richiesta la prossima volta.
Una semplice dimostrazione è la seguente:
bool isPersistent, //se persistere (impostato secondo necessità, se impostato su persistenza, l'impostazione Expires del cookie deve essere impostata quando si invia un cookie)
Il sesto parametro di FormsAuthenticationTicket memorizza l'userData della stringa di tipo, dove è memorizzato l'ID ruolo dell'utente corrente, separato da una virgola.
Quando si effettua l'accesso con un nome utente "test", appare un cookie di log sul client
2. Ottenere informazioni sulle certificazioni
Dopo aver effettuato il login, nella pagina dei contenuti, possiamo ottenere le informazioni uname tramite il User.Identity.Name della richiesta corrente, oppure possiamo decifrare il cookie nella richiesta per ottenere il ticket, e poi ottenere uname e userData (cioè le informazioni ID ruolo precedentemente memorizzate) da esso.
3. Realizzare il controllo di accesso ai permessi tramite attributi di annotazione
Configura, abilita l'autenticazione dei moduli e la gestione dei ruoli in web.config
Quando aggiungiamo le proprietà di annotazione a Controller e Action, da dove otteniamo il ruolo definito? Poiché non utilizziamo l'autenticazione basata sull'abbonamento, creeremo anche un RoleProvider personalizzato. Il nome è CustomRoleProvider, che deriva da RoleProvider. Ecco la creazione del tuo file CustomRoleProvider.cs nella cartella Helper sotto MVCApp.
Ci sono molti metodi astratti in RoleProvider, e implementiamo il metodo GetRolesForUser solo per ottenere i ruoli utente. Il ruolo utente qui può essere consultato dal database in base all'ID utente ottenuto, oppure a quello memorizzato nella sessione o nel cookie. Qui ho già memorizzato il ruolo nell'userData del ticket, quindi otteniamolo dal ticket.
Se necessario, aggiungere attributi di annotazione al Controller o all'Azione validata, ad esempio, questa Azione consente l'accesso solo con un RoleID pari a 1, 2 o 3, e l'attuale RoleID dell'utente è (7, 1, 8), il che significa che l'utente ha il diritto di accedere.
P.S. :1. Il ticket viene memorizzato al momento della scadenza del cookie, e se il browser è chiuso per ricordare il ticket corrente, i parametri possono essere impostati quando viene istianziato il FormsAuthenticationTicket.
2. L'acquisizione del Ruolo può essere letta direttamente dal database senza essere memorizzata negli userData del ticket, e l'userData può memorizzare altre informazioni.
3. Se vuoi configurare in modo flessibile i Ruoli di Accesso Permesso di Controller e Action, puoi personalizzare il metodo OnAuthorization nell'override AuthorizeAttribute, in cui viene utilizzato il metodo
Leggi l'ID del ruolo consentito nella pagina corrente e controllalo in base al RoleID dell'utente corrente. In questo modo si realizza la configurazione flessibile del ruolo.
4. Le informazioni nel ticket vengono memorizzate nel cookie, e la sicurezza è comunque a tua discrezione; personalmente penso sia meglio memorizzare UserID e RoleID nella sessione.
|
Pubblicato su 19/07/2018 17:31:14
|
|
|
