Profilo utente ASP.NET vs utilizzo dei cookie

Question

Penso che, in quasi tutti i casi, i dati delle preferenze dell'utente possano essere memorizzati in un cookie con (quasi) risultati altrettanto buoni di quando si utilizza l'API del profilo utente. Gli svantaggi dell'utilizzo dei cookie (per utenti autenticati) sembrano essere la possibilità di eliminare o timeout un cookie, nel qual caso i dati delle preferenze dell'utente andranno persi. Per gli utenti anonimi, se i dati delle preferenze devono essere mantenuti tra le sessioni, è necessario utilizzare un cookie anche quando si utilizzano i profili utente.

Quindi quali sono alcuni dei maggiori vantaggi / svantaggi dell'utilizzo dei profili utente o dei cookie per la memorizzazione delle preferenze dell'utente?

Answer 1

Un altro svantaggio di conservare tutti i dati delle preferenze nei cookie è che tutti questi dati dovranno essere inviati in ogni richiesta dal client e in qualsiasi risposta dal server ogni volta che viene apportata una modifica ai dati. Mentre questo può sembrare un punto secondario nell'era della banda larga, è ancora un ulteriore sovraccarico. L'uso dell'API di Profili significa che i dati sono conservati sul server e che solo un cookie di identificazione della sessione deve essere inviato dal browser.

Inoltre, come hai affermato, per gli utenti anonimi se i cookie vengono eliminati, le preferenze dell'utente contenute nel DB dei profili non saranno più accessibili. Tuttavia, questo non sarà il caso degli utenti registrati del tuo sito Web. Se rimuovono i loro cookie, il server sarà comunque in grado di recuperare le preferenze dell'utente al successivo accesso.

Answer 2

Uno dei vantaggi della registrazione su un sito è che ricorda le mie preferenze: se stai memorizzando tali informazioni in un cookie sul mio computer anziché sul tuo server, quando accedo al tuo sito da un altro computer, io ' devo reimpostare tutte le mie preferenze - dal punto di vista dell'usabilità, questo è abbastanza male.

Per un utente anonimo, archiviare le preferenze in un cookie può sembrare abbastanza sensato: non sai chi sono o se torneranno e, come dici, non puoi allenarti da una sessione alla accanto a chi sono - tuttavia probabilmente sarebbe meglio archiviare una sorta di token nel cookie e mapparlo su un archivio delle preferenze sul server.

Inoltre, ho notato che diversi browser hanno implementazioni diverse per i cookie, ad esempio IE ora può ricevere 50 cookie di un dominio (rispetto ai 20 originali), ma è ancora limitato a un totale di 4096 byte per l'intera raccolta di cookie (e precedenti) - altri browser supporteranno 4KB per cookie, anziché per dominio.

Answer 3

I cookie hanno una lunghezza massima limitata e utilizzano un'implementazione al di fuori del tuo controllo (dopo tutto, sono una caratteristica del browser dei visitatori). Personalmente, non mi piace fare affidamento su implementazioni di terze parti sconosciute sulle quali non ho alcun controllo e, se devo, sto cercando di usarlo nel modo più semplice possibile.

Quindi da dove vengo, memorizzerei sempre i dati dell'utente sul server e passerei semplicemente un cookie che punta a tali informazioni.

Oltre a non fidarsi del browser con una porzione potenzialmente grande di dati (che potrebbero essere persi, archiviati in modo errato o non archiviati a seconda non solo del browser ma anche, diciamo, di un'applicazione antivirus o altro), questo ha vari altri vantaggi:

• Stai nascondendo la tua implementazione all'utente: se memorizzi i dati nel cookie, sono visibili a chiunque e possono essere analizzati o modificati a piacimento. Ciò può anche portare gli utenti a modificare i cookie in base alle proprie preferenze e, quindi, costringerti a mantenere roba intorno a te probabilmente vuoi sbarazzartene solo perché alcuni utenti dipendono dalla tua particolare implementazione in qualsiasi momento.
• Poiché i cookie sono memorizzati in testo semplice, su macchine condivise, tutti non possono più vedere facilmente tutte le impostazioni effettuate dall'utente precedente, né modificarle a piacimento.

Ma il punto più importante rimane la disconnessione dalle implementazioni del browser non abbastanza funzionanti (solo la memorizzazione di piccoli token è il caso d'uso comune testato)

Answer 4

Non dimenticare che uno dei maggiori svantaggi dell'utilizzo dei cookie è che possono essere copiati, quindi è pericoloso archiviare informazioni di autenticazione su di essi.

Non ho familiarità con l'API del profilo utente, ma suppongo che memorizzi le informazioni sul server (?). In tal caso, potresti avere un problema se devi avere molti utenti.

Nel complesso, forse la soluzione migliore è utilizzare il profilo utente se garantisce la persistenza delle informazioni.

Answer 5

Tieni presente che è possibile scrivere un ProfileProvider che persiste i dati dell'utente in un cookie, in modo da poter avere il meglio di entrambi i mondi se determini che lo stato che desideri persistere è appropriato per i cookie (dimensioni, sicurezza, ecc.) .

Answer 6

In realtà, non è necessario conservare i dati delle preferenze nei cookie per utenti anonimi quando si utilizza il provider di profili ASP.NET. Memorizza semplicemente l'ID utente corrente (che è una stringa relativa alla sessione dall'aspetto orribile) in un cookie. Questo diventa il precedente UserID nelle visite successive, quindi puoi semplicemente prendere le informazioni del vecchio profilo e migrarle al profilo corrente, o persino autenticarle come quel vecchio profilo anonimo.