La sessione Web è "Bad Design"? Perché?

13

l'altro giorno stavo discutendo con un collega ed è uscito dicendo che usare la sessione dell'utente in un'applicazione web è sbagliato. Ho risposto che potrebbe essere sbagliato a seconda delle informazioni che stai memorizzando, altrimenti perché un servizio di sessione Web dovrebbe essere fornito da Microsoft (stavamo parlando di ASP.NET).

Mi ha risposto, ancora una volta, che anche nella SM potevano facilmente rispondermi che era una cattiva progettazione. E che potrebbe mostrarmi alcuni white paper che lo dimostrano.

Purtroppo non ho più l'opportunità di contattare questo ragazzo, ma vorrei davvero capire di più sul suo punto di vista. Qualcuno ha informazioni / punti di vista al riguardo qui?

web-applications

— abx78
fonte

2

Il protocollo HTTP era originariamente progettato per essere "stateless", in modo che tutte le transazioni fossero singolari e basate sulle informazioni fornite. Le sessioni sono un modo per aggirare questo in alcuni usi. Praticamente, tuttavia, per molti siti Web moderni, non riesco a pensare a un modo semplice per evitare le sessioni; forse non sono abbastanza creativo.

— Katana314,

@ Katana314 Archiviazione del database con i cookie. Puoi utilizzare le sessioni per informazioni di base come l'identificazione dell'utente, ma molte implementazioni di sessione (in particolare in Django, che abbiamo riscontrato più volte) hanno difetti che possono creare condizioni di gara con più dati transitori ogni volta che più richieste da parte dello stesso utente vengono inviati immediatamente (come per le chiamate AJAX)

— Izkata,

2

L'archiviazione del database con i cookie è solo una questione di ospitare la sessione in un database.

— Alan Shutko,

11

Non penso che intendesse "design cattivo" tanto quanto "cattiva pratica". In generale, un'applicazione web dovrebbe essere il più apolida possibile. Anche se, ad esempio, potrebbe essere necessario conoscere le informazioni dell'utente per autorizzare la visualizzazione della pagina, tali informazioni potrebbero essere salvate sul computer client sotto forma di cookie e il server convalida semplicemente le informazioni dell'utente ogni volta.

Sarebbe l'ideale, ma non puoi sempre contare sul fatto che il client sia in grado di salvare i cookie. Inoltre, comporta la convalida dell'utente in modo apolide, il che comporta potenzialmente la ricerca di informazioni dal database per una semplice richiesta di pagina. Spesso è più semplice salvare tali informazioni nella sessione.

Tuttavia, una volta attraversato Rubicon, molti programmatori sono tentati di salvare non solo le informazioni di autenticazione nella sessione, ma anche molte altre cose. Questo è un anti-schema e tende a rendere la tua applicazione web fortemente dipendente dallo stato, che è precisamente ciò che si supponeva fosse evitato in primo luogo.

Alcuni programmatori si baserebbero su una tecnologia come Spring (se si utilizza Java) per districare ciò che altrimenti sarebbe un casino di dipendenze, ma direi che ciò semplifica la creazione di dipendenze anziché eliminarle. Tali tecnologie dovrebbero aiutare il tuo sviluppo, non rendere il tuo anti-pattern meno un problema.

Pertanto, una buona regola empirica è che se riesci a scriverlo senza stato, è probabilmente una buona idea farlo o rischi di cadere in questa trappola. Ovviamente ti imbatterai in situazioni in cui ciò è richiesto, ma in generale, dovresti solo salvare informazioni che altrimenti sarebbero difficili da riacquisire.

— Neil
fonte

1

but you can't always count on the client being able to save cookiesquindi AFAIK, non puoi contare nemmeno sulle sessioni. I cookie non vengono utilizzati per identificare quale sessione appartiene a quale utente o esistono altri metodi e questo è semplicemente il più comune?

— Izkata,

Le informazioni sulla sessione vengono normalmente salvate sul server per ogni connessione server / client e questo è diventato una tendenza popolare per i siti Web di grandi dimensioni che non potevano contare sul fatto che gli utenti avessero i cookie abilitati. Esistono opzioni (e / o librerie js) che impongono il salvataggio di tali informazioni sul PC client (che è diventato molto popolare negli ultimi tempi), ma senza HTML 5, i cookie sono l'unico modo per raggiungere questo obiettivo. Per quanto ne sappia, non ci sono altri modi per farlo.

— Neil,

8

Penso che tu stia confondendo due diversi argomenti: 1) sessioni e 2) il modello di pagina dei moduli web asp.net

Una sessione Web è necessaria per l' autenticazione di un utente. Idealmente una sessione dovrebbe essere utilizzata solo per questo scopo. Non dovresti archiviare i dati dell'utente in una sessione (che si tratti del server, di un cookie o come asp.net/webforms fa: all'interno della pagina stessa). Nessuno dovrebbe dire che una sessione web è male, ma piuttosto, la memorizzazione dei dati dell'utentein una sessione è una cattiva pratica. Le ragioni per non archiviare i dati utente sul server includono gli stessi motivi per evitare variabili globali. La memorizzazione dei dati dell'utente nei cookie o nella pagina può comportare problemi di sicurezza. L'uso del modello di pagina di asp.net, inoltre, non aderisce alla natura apolide del web. Potresti fare una ricerca per scoprire di più sul perché i moduli web sono un cattivo design. Le sessioni invece sono una parte necessaria delle applicazioni web.

— programmatore
fonte

"Le sessioni invece sono una parte necessaria delle applicazioni web." No.

— masterxilo

6

I controlli e la memorizzazione dello stato della sessione su una pagina sono essenzialmente un hack. È il caso della SM - una necessità perché volevano essere in grado di fornire un ambiente di sviluppo in cui si potesse progettare pagine come è possibile in ambienti winform.

Gli stessi Stati membri si sono spostati verso l'architettura MVC (ultima versione - MVC 4) che è più un ritorno a ciò che il protocollo dovrebbe essere effettivamente - senza stato.

Ci sono situazioni in cui lo stato di archiviazione è ancora utile ma si dovrebbe capire che questa è l'eccezione piuttosto che la regola.

— Robbie Dee
fonte