confronto tra le modalità di mantenimento dello stato

Question

Esistono vari modi per mantenere lo stato utente utilizzando nello sviluppo web.

Questi sono quelli che mi vengono in mente in questo momento:

1. Stringa della domanda

2. Biscotti

3. Metodi del modulo (ricevi e pubblica)

4. Viewstate (solo ASP.NET immagino)

5. Sessione (server Web InProc)

6. Sessione (server web dedicato)

7. Sessione (database)

8. Persistenza locale (Google Gears) (grazie Steve Moyer) ecc.

So che ogni metodo ha i suoi vantaggi e svantaggi, ad esempio i cookie non sono sicuri e QueryString ha un limite di lunghezza ed è semplicemente brutto da guardare!;)

Ma quando progetto un'applicazione web sono sempre confuso su quali metodi utilizzare per quale applicazione o quali metodi evitare.

Quello che vorrei sapere è quali metodi usi generalmente e consiglieresti o, cosa più interessante, quale di questi metodi vorresti evitare in determinati scenari e perché?

Answer 1

Sebbene sia una domanda molto complicata a cui rispondere, ho alcune cose a cui pensare rapidamente quando considero l'implementazione dello stato.

• Lo stato della stringa di query è utile solo per le attività più elementari, ad esempio mantenere la posizione di un utente all'interno di una procedura guidata, ad esempio, o fornire un percorso a cui reindirizzare l'utente dopo aver completato una determinata attività (ad esempio, l'accesso).Altrimenti, lo stato della stringa di query è terribilmente insicuro, difficile da implementare e, per rendergli giustizia, deve essere collegato a una macchina a stati lato server contenente una chiave per collegare il client allo stato mantenuto dal server per quel client.
• Lo stato dei cookie è più o meno lo stesso: è solo più elaborato dello stato della stringa di query.Ma è ancora totalmente mantenuto sul lato client, a meno che i dati nel cookie non siano una chiave per collegare il client a qualche macchina a stati lato server.
• Lo stato del metodo del modulo è ancora simile: è utile per nascondere i campi che collegano un dato modulo ad alcuni dati sul back-end (ad esempio, "questo utente sta modificando il record n. 512, quindi il modulo conterrà un input nascosto con il valore 512").Non è utile per molto altro e, ancora una volta, è solo un'altra implementazione della stessa idea dietro la stringa di query e lo stato dei cookie.
• Lo stato della sessione (qualsiasi modo tu descriva) è fantastico, poiché è infinitamente estensibile e può gestire tutto ciò che il linguaggio di programmazione scelto può gestire.Il primo avvertimento è che deve esserci una chiave in mano al client per legare quel client al suo stato archiviato sul server;è qui che la maggior parte dei framework Web fornisce al client una chiave basata su cookie o su stringa di query.(Quasi tutti i moderni utilizzano i cookie, ma ricorrono alle stringhe di query se i cookie non sono abilitati.) Il secondo avvertimento è che è necessario riflettere un po' sul modo in cui si memorizza il proprio stato...lo inserirai in un database?Il tuo framework web lo gestisce interamente per te?Ancora una volta, la maggior parte dei framework web moderni eliminano tutto questo lavoro e per poter implementare la mia macchina a stati, ho bisogno di un molto buona ragione...in caso contrario, è probabile che creino buchi di sicurezza e interruzioni di funzionalità che sono state eliminate nel tempo in uno qualsiasi dei framework maturi.

Quindi immagino di non poter davvero immaginare di non voler utilizzare lo stato basato sulla sessione per altro che per il motivo più banale.

Answer 2

Anche la sicurezza è un problema;i valori nella stringa di query o nei campi del modulo possono essere facilmente modificati dall'utente.L'autenticazione dell'utente deve essere salvata in un cookie crittografato o a prova di manomissione o nella sessione lato server.Tenere traccia dei valori passati in un modulo mentre un utente completa un processo, come la registrazione a un sito, che probabilmente può essere conservato nei campi del modulo nascosti.

La cosa bella (e talvolta pericolosa), però, della stringa di query è che lo stato può essere rilevato da chiunque faccia clic su un collegamento.Come accennato in precedenza, questo è pericoloso se fornisce all'utente un'autorizzazione che non dovrebbe avere.È carino, però, mostrare ai tuoi amici qualcosa che hai trovato sul sito.

Answer 3

Con il crescente utilizzo del Web 2.0, penso che nella tua lista manchino due metodi importanti:

8 applicazioni AJAX: poiché la pagina non si ricarica e non esiste navigazione da pagina a pagina, lo stato non è un problema (ma i dati utente persistenti devono utilizzare le chiamate XML asincrone).

9 Persistenza locale: le applicazioni basate su browser possono rendere persistenti i dati utente e lo stato sul disco rigido locale utilizzando librerie come Google Gears.

Per quanto riguarda quale sia il migliore, penso che tutti abbiano il loro posto, ma il metodo Query String è problematico per i motori di ricerca.

Answer 4

Personalmente, poiché quasi tutto il mio sviluppo web è in PHP, utilizzo i gestori di sessione di PHP.

Le sessioni sono le più flessibili, secondo la mia esperienza:normalmente sono più veloci degli accessi al database e i cookie che generano muoiono quando il browser si chiude (per impostazione predefinita).

Answer 5

Evita InProc se prevedi di ospitare il tuo sito web su un host economico e allegro come webhost4life.Ho imparato a mie spese che, poiché i loro sistemi sono sovrascritti, riciclano le applicazioni molto frequentemente, il che fa sì che la sessione vada persa.Molto noioso.

Il loro suggerimento è di utilizzare StateServer, il che va bene, tranne per il fatto che devi serializzare/deserializzare la sessione ogni volta che ripubblica.Adoro gli oggetti e la mia web app ne è piena.Sono preoccupato per le prestazioni quando si passa a StateServer.Devo eseguire il refactoring per inserire solo le cose di cui ho veramente bisogno nella sessione.

Vorrei saperlo prima di iniziare...

Saluti, Rob.

Answer 6

Fai attenzione allo stato in cui memorizzi lato client (stringhe di query, campi modulo, cookie).Tutto ciò che riguarda la sicurezza non dovrebbe essere archiviato sul lato client, tranne forse un identificatore di sessione se è ragionevolmente nascosto e difficile da indovinare.Esistono troppi siti Web che dispongono di impostazioni come "authenticated=true" e le memorizzano in un cookie, una stringa di query o un campo modulo nascosto.È banale per un utente ignorare qualcosa del genere.Ricorda che QUALSIASI input proveniente da un client potrebbe essere stato manomesso e non dovrebbe essere considerato attendibile.

Answer 7

Cookie firmati collegato a una sorta di archivio di database quando è necessario acquisire dati.Non c'è motivo di archiviare i dati sul lato client se si dispone di un back-end connesso;stai solo cercando guai se questo è un sito web rivolto al pubblico.

Answer 8

Non è tanto una questione di cosa usare e cosa evitare, ma quando usare quale.Ognuno ha circostanze particolari quando è il migliore, e una circostanza diversa quando è il peggiore.

Il fattore decisivo è generalmente la durata dei dati.Lo stato della sessione dura più a lungo dei campi del modulo e così via.