scegliere tra richieste di identità asp e dati di sessioni

Question

Sto tentando di scegliere tra la memorizzazione di dati specifici dell'utente nella mia applicazione MVC come rivendicazioni di identità o come dati di sessione per ridurre il numero e la frequenza di round trip del database sulle richieste. Tuttavia, considerando le prestazioni, la sicurezza e altre considerazioni sulle migliori pratiche, non so quale strada percorrere.

Apprezzerò qualsiasi suggerimento su questo.

Answer 1

IMO (e il suo solo la mia opinione) in base a ciò che so di reclami, i biscotti e le regole di memorizzazione:

Prestazioni saggio non ho mai visto una differenza tra rivendicazioni e di stoccaggio di sessione (a meno che il cookie diventa grande da MOLTE affermazioni) entrambi sembrano avere lo stesso impatto sulle prestazioni per quanto riguarda la velocità (entrambi devono cercare i dati da qualche parte (CLaims = cookie, sessione = memoria dell'unità server) come per la migliore pratica che potrebbe cadere lungo le righe di quanto MUCH dati hai bisogno di memorizzare

Da quello che ho visto nella mia esperienza (correggimi se ho torto) ma i dati di sessione sono memorizzati su disco sul server ed è fondamentalmente onl i tuoi server disco rigido spazio libero per limiti di dimensione ecc. considerando che i cookie hanno un limite di dimensioni dei dati codificati e più rivendicazioni memorizzi più grande di quel cookie, quindi se dici che il cookie è al massimo, il cliente potrebbe vedere un colpo nel fatto che invia tutti i dati dei cookie in ogni richiesta al sito, dove come con Session il server cerca i dati localmente e ci sono meno dati inviati dal browser.

quindi il mio parere delle migliori prassi è che se i dati persistenti per salvare il database di ricerca è un ingombro ridotto poi in realtà non è una pratica migliore ad esso basta usare quello che preferite, ma se la vostra la memorizzazione di un sacco di bit in particolare le stringhe quindi la sessione sarebbe la migliore pratica secondo me in quanto salva i dati di andata e ritorno tra client/server e non ha il limite di dimensioni che potresti incontrare a un certo punto e poi tirare fuori i capelli chiedendoti perché i tuoi dati non sono ci sono (fatto questo in passato me stesso perché se il cookie è troppo grande il client si rifiuta silenziosamente e ci sono voluti 3 giorni per capire che era la dimensione del cookie)

Answer 2

Il modo in cui si memorizzano i dati utente per la propria app dipende molto dall'applicazione stessa. Ma come guida, usare l'autenticazione basata sulle attestazioni e archiviare le attestazioni in un cookie di sessione è un approccio molto comune. Date un'occhiata all'identità di asp.net - http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity

Dovreste essere in grado di ottimizzare i dati memorizzati nel cookie di sessione. Ad esempio: - se la tua applicazione ha sempre bisogno di visualizzare il nome dell'utente su ogni pagina, puoi avere il claim del nome nel cookie di sessione. Ma se è necessario visualizzare altre informazioni utente come indirizzo, azienda ecc. In una sola pagina 'profilo utente', è possibile interrogare quei dettagli in un database usando la richiesta 'nameidentifier' memorizzata nel cookie di sessione. Se si esamina l'identità di ASPNET, si noterà che non sarà necessario utilizzare il cookie di sessione direttamente come middleware di autenticazione dei cookie per assicurarsi che le attestazioni siano disponibili tramite la proprietà User (o ClaimsPrinciple.Current) del controller MVC. È necessario decidere quali attestazioni dovrebbero essere disponibili per tutte le richieste tramite la proprietà User e Quali proprietà dell'utente dovrebbero essere interrogate tramite un database di UserInformation. Ovviamente, è necessario memorizzare la chiave (nomeidentificatore o email) nel database delle informazioni utente nelle attestazioni, in modo da poter eseguire query nel database ogni volta che lo si desidera.