2010-02-10 21 views

risposta

5

I cookie possono persistere più di una singola sessione. Tuttavia, i cookie possono anche essere cancellati dall'utente, oppure potresti avere un utente il cui browser non accetta i cookie (nel qual caso solo una sessione lato server funzionerà).

6

Nella maggior parte dei casi, lo stato della sessione viene mantenuto utilizzando i cookie. Quindi non è veramente una questione dell'uno o dell'altro, ma come usarli insieme.

L'utilizzo dell'infrastruttura di sessione del framework può semplificare le cose, ma lo stato del tracciamento manualmente con i cookie di solito offre un controllo più dettagliato. La soluzione corretta dipende da ciò che stai cercando di realizzare.

+1

"La soluzione corretta dipende da ciò che stai cercando di ottenere." Credo che sia esattamente quello che la domanda sta cercando di ottenere ... – sprugman

1

Le sessioni sono memorizzate sul server. Se memorizzi qualcosa in un cookie, il browser dell'utente invia tali informazioni ad ogni richiesta, rallentando potenzialmente il tuo sito dal punto di vista dell'utente. Cerco di evitare di usare i cookie quando posso.

+4

Ma quando si utilizza una sessione, il server invierà comunque un cookie di sessione ad ogni richiesta. Penso che quello che stai cercando di dire è che un minimo di dati dovrebbe essere conservato nei cookie, dal momento che tutti i dati dei cookie dovranno essere inviati attraverso la rete su ogni richiesta e risposta HTTP. –

+0

I cookie non "rallentano un sito" mettono le cose nel contesto. un paio di byte non strutturati non contano nulla. –

2

I cookie vengono inviati al server ad ogni richiesta, quindi se si prevede di archiviare una discreta quantità di dati, memorizzarli in sessione, altrimenti se si memorizzano piccole quantità di dati, un cookie andrà bene. Tutti i dati sensibili devono essere archiviati in sessione, poiché i cookie non sono sicuri al 100%. Un vantaggio dei cookie è che è possibile salvare memoria sul server che normalmente memorizzerebbe i dati di sessione.

43
  • Le sessioni vengono memorizzate sul server, il che significa che i client non hanno accesso alle informazioni memorizzate. I dati di sessione, memorizzati sul server, non devono essere trasmessi integralmente con ciascuna pagina; i client devono solo inviare un ID e i dati vengono caricati dal server.

  • D'altra parte, i cookie sono memorizzati sul client. Possono essere resi durevoli per molto tempo e ti consentono di lavorare in modo più fluido quando hai un gruppo di server web. Tuttavia, a differenza di Sessioni, i dati memorizzati nei cookie vengono trasmessi per intero con ogni richiesta di pagina.

  • evitare di memorizzare i dati in cookie

    • si può vedere, leggere e manipolati da parte dell'utente finale, o intercettati da quelli con intenti nefasti. Non puoi fidarti di alcun dato nei cookie, ad eccezione di "session_id".
    • Aumenta la larghezza di banda, se si aggiunge 1k di dati per richiesta di pagina per utente, ciò potrebbe aumentare la larghezza di banda del 10-15%. Questo forse non è costoso da una prospettiva $$, ma potrebbe essere dal punto di vista delle prestazioni. Riduce in modo efficace la larghezza di banda su un server per 10-15%, cioè potrebbe causare la necessità di più server.
  • Ciò che è possibile memorizzare nei dati di sessione dipende dalla quantità di dati e dal numero di utenti che si hanno. no_of_users * size_of_session_data deve essere inferiore alla memoria disponibile sul server.

+3

anche da notare, i dati di sessione vanno persi se il server web viene riavviato – Ben

+2

@Ben, non sempre vero, PHP utilizza i file per persistere le sessioni e sono quindi resistenti a un riavvio (come è un archivio db). Generalmente perdi solo i dati di sessione quando sono persistenti in memoria e o stai usando un server di applicazione Glassfish, ecc. –

+0

@ Ben: Tecnicamente puoi anche avere sessioni persistenti. Puoi avere sessioni memorizzate in un database, o sul filesystem, per esempio. In effetti alcune applicazioni richiedono sessioni persistenti per tenere traccia degli audit di chi ha avuto accesso alle risorse dell'applicazione. –

5

I cookie sono lato client, le sessioni sono lato server. Utilizza i cookie per piccole porzioni di dati di cui puoi fidarti (come le impostazioni dei caratteri, il tema del sito, ecc.) E per gli ID opachi per i dati lato server (come l'ID di sessione). Aspettatevi che questi dati possano essere persi in qualsiasi momento e che non possono essere considerati attendibili (vale a dire che devono essere disinfettati). Utilizzare i dati di sessione per blocchi di dati più grandi (per molti sistemi è possibile memorizzare oggetti, strutture dati, ecc.) E quelli di cui ci si deve fidare, come lo stato di autorizzazione, ecc. In generale, utilizzare i dati di sessione per archiviare dati di stato più grandi.

È possibile memorizzare elementi come lo stato di autorizzazione anche nei cookie, se necessario per la GUI, la memorizzazione nella cache, ecc., Ma non fidarsi mai e non fare affidamento sulla sua presenza. I cookie sono facili da eliminare e facili da falsificare. I dati di sessione sono molto più difficili da falsificare, poiché la tua app lo controlla.

10
  • sessione di utilizzo sempre
  • uso dei cookie solo se avete bisogno di più sessioni registrate-in - quindi aggiungere un cookie con un ID utente crittografato.
+5

Le prestazioni del server non sono un problema se si dice "usa sempre le sessioni"? – Jorre

0

Utilizzare sessions solo se i dati è troppo grande per cookies o se i dati è così grande che farebbe diminuire le prestazioni se si è utilizzato cookies.

Ad esempio, se si sta salvando i dati più piccoli quindi le dimensioni di un session id nel vostro cookie, come 2 gettoni d'accesso o qualcosa di simile ... allora io non vedo il motivo per cui si usa sessions sopra cookies.

Si noti inoltre che i file di sessione PHP vengono salvati su disco per impostazione predefinita, rispetto ai cookie, che vengono salvati solo sul lato client.

0

Le sessioni sono memorizzati sul server side.If un negozi visitatore qualcosa in un cookie, il browser invierà le informazioni utente per ogni richiesta fatta, questo tende a consumare un sacco di tempo server computer e rallentare gli utenti experience.Some browser, inoltre, non supportano i cookie che danno più vantaggio per le sessioni nel corso cookies..i consiglia vivamente sito sessions.This potrebbe aiutare http://php.net/manual/en/features.cookies.php grazie

0

vostra guida definitiva

NB - cookie è memorizzato su utente s browser, La sessione viene memorizzata sul computer del server di hosting.

Quando utilizzare

  1. Utilizzare un cookie quando si desidera la vostra applicazione per ricordare i dati degli utenti sempre, anche quando hanno chiuso il proprio browser. Ogni volta che si digita www.Facebook.com, si accede al proprio account, anche quando il browser è stato chiuso e riaperto.

    Poiché tutti i dati conservati in una sessione vengono cancellati una volta chiuso il browser.

  2. Utilizzare un cookie quando le informazioni dell'utente da memorizzare sono molto più grandi del normale. ... Con la sessione se hai una base utenti più ampia come Facebook, pensa a come sembrerà memorizzare tutte le sessioni utente sul computer host.

  3. Utilizzare una sessione quando le informazioni utente da memorizzare non sono più grandi del normale e non si desidera che il pubblico abbia accesso alle variabili utente ...

0

Uno degli svantaggi di sessioni PHP è come la gestione della sessione opere. In particolare, solo una procedura/richiesta può avere una sessione aperta per la scrittura alla volta. Su

session_start() 

il file di sessione è bloccato. Se arrivano altri processi, il resto si accumula e aspetta il loro turno.

In altre parole, se si sta utilizzando AJAX su una pagina per aggiornare diversi elementi - non si desidera che le richieste AJAX aprano la stessa sessione - saranno forzati in una coda e se una di tali richieste rimane bloccata - non rilascerà la sessione - causando un blocco del browser in cui aprire una nuova scheda o finestra mette solo un'altra richiesta non disponibile nella coda sul server. L'utilizzo di

session_write_close() 

il prima possibile per rilasciare la sessione è un parziale aggiramento.

Una lunga richiesta in esecuzione con un utente che si annoia e che apre più finestre potrebbe avere lo stesso effetto di sospensione del browser.

Raccomando di evitare sessioni PHP.

Problemi correlati