Informazioni sull'utente in Nancy

Question

Sto mettendo insieme un'app demo basata su Nancy.Demo.Authentication.Forms.

che sto attuazione Claims e UserName nella mia classe UserIdentity:IUserIdentity e, come per la demo, ho un UserModel con UserName.

Nella classe SecureModule, posso vedere che la Context.CurrentUser può essere utilizzato per vedere chi è che è connesso, ma come per l'interfaccia, questo fornisce solo il nome utente e rivendicazioni. Se poi ho bisogno di ottenere più dati (ad esempio messaggi per l'utente connesso) per un modello di visualizzazione, tutto quello che posso vedere come filtro per una query db è il nome utente, che sembra, beh, strano. Preferirei piuttosto usare l'identificatore univoco dell'utente.

Penso a cosa sto cercando di andare a fondo, se è meglio aggiungere i campi extra alla mia implementazione IUserIdentity o allo UserModel? E dove popolare questi?

Non sono sicuro che la mia domanda sia chiara (non è chiaro nella mia testa!), Ma alcuni consigli di architettura generale di base sarebbero un vero toccasana.

Answer 1

dispiace per la risposta ritardata .. po 'frenetica in questo momento :)

L'IUserIdentity è l'interfaccia minima richiesta per utilizzare costruito in aiutanti di autenticazione, è possibile implementare che e aggiungere più informazioni aggiuntive di Nancy come ti piace alla tua classe; è simile allo standard .net IPrincipal. Se aggiungi le tue informazioni dovrai ovviamente trasmettere al tuo tipo di implementazione per accedere ai campi aggiuntivi. Potremmo aggiungere un metodo CurrentUser per impedirti di farlo, ma sembra un po 'ridondante.

È possibile smettere di leggere qui, se ti piace, o si può leggere su se siete interessati a come le forme di autenticazione funziona ..

FormsAuth utilizza un'implementazione del IUsernameMapper (che è probabilmente il nome sbagliato ora) per convertire tra l'identificatore utente Guid memorizzato nel cookie client e l'utente effettivo (IUserIdentity). Vale la pena notare che questo GUID deve essere mappato su user/id da qualche parte, ma non è inteso per essere la chiave primaria del database, è semplicemente uno strato di riferimento indiretto tra i nomi utente/nomi (probabilmente prevedibili) e il "token" memorizzato sul client. Anche se i cookie sono crittografati e HMACd (a seconda della configurazione), se qualcuno riesce a crackare e ricostruire il cookie auth, dovrebbe indovinare il GUID di qualcun altro per impersonarli, piuttosto che cambiare un nome utente (in "admin") o qualcosa di simile), o un id (a 1 per il primo utente).

speranza che abbia un senso :)