2009-03-24 18 views
138

Se un utente ha effettuato l'accesso al mio sito, con il suo ID memorizzato in $_SESSION, e dal suo browser ha fatto clic su un pulsante "Salva" che effettuava una richiesta AJAX al server. I suoi $_SESSION e i cookie verranno conservati in questa richiesta e posso contare in modo sicuro sull'id presente nello $_SESSION?Le richieste AJAX mantengono le informazioni sulla sessione PHP?

risposta

169

La risposta è sì:

Le sessioni sono mantenute sul lato server. Per quanto riguarda il server, non vi è alcuna differenza tra una richiesta AJAX e una normale richiesta di pagina. Sono entrambe richieste HTTP e contengono entrambe le informazioni sui cookie nell'intestazione allo stesso modo.

Dal lato client, gli stessi cookie verranno sempre inviati al server sia che si tratti di una richiesta regolare o di una richiesta AJAX. Il codice Javascript non ha bisogno di fare nulla di speciale o anche di essere a conoscenza di ciò che accade, funziona esattamente come fa con le richieste regolari.

+8

Followup: il server può impostare un flag 'HttpOnly' quando si imposta un cookie, il che significa che Javascript non sarà in grado di vedere il cookie. Tuttavia, il cookie * sarà * inviato * sia per AJAX che per le richieste di pagine regolari e continuerà a funzionare esattamente allo stesso modo. Il tuo Javascript non lo vedrà in 'document.cookie'. – thomasrutter

20

Se il file PHP le richieste AJAX ha un session_start() le informazioni sulla sessione verranno mantenute. (escludendo le richieste rientrano nello stesso dominio)

+2

infatti, è quello che mi sono dimenticato di fare :-) – sivann

23

Quello che stai realmente ottenendo è: i cookie inviati con la richiesta AJAX? Supponendo che la richiesta AJAX sia relativa allo stesso dominio (o all'interno dei limiti del dominio del cookie), la risposta è sì. Quindi, le richieste AJAX allo stesso server mantengono le stesse informazioni sulla sessione (supponendo che gli script denominati emettano un session_start() come per ogni altro script PHP che vuole accedere alle informazioni sulla sessione).

+1

potrei sbagliarmi, ma ho pensato che non era nemmeno possibile inviare le richieste Ajax per altri domini (sottodomini esclusi)? –

+0

Potrebbe essere in grado di imbrogliare con il trucco di script dinamico. Non stanco mai però. – cletus

+1

Sì, le richieste Ajax non possono essere inoltrate ad altri domini. Tuttavia, puoi inserire dinamicamente un tag

0

Una cosa da tenere a mente, in particolare se si utilizza un framework, è controllare se l'applicazione sta rigenerando gli ID di sessione tra le richieste - tutto ciò che dipende esplicitamente dall'ID di sessione si imbatterà in problemi, anche se ovviamente il resto dei dati nella sessione non saranno interessati.

Se l'applicazione sta rigenerando gli ID di sessione come questa, allora si può finire con una situazione in cui una richiesta Ajax in effetti invalida/sostituisce l'ID di sessione nella pagina richiedente.

0

Ecco cosa fanno i quadri, ad es. se si inizializza la sessione in Front Controller o nello script boostrap, non ci si dovrà preoccupare della sua inizializzazione né per i controller di pagina né per i controller di ajax. I framework PHP non sono una panacea, ma fanno così tante cose utili come questa!

8

Beh, non sempre. Utilizzando i cookie, sei bravo. Ma lo "posso contare sulla sicurezza dell'id presente" mi ha spinto a estendere la discussione con un punto importante (principalmente per riferimento, poiché il numero di visitatori di questa pagina sembra piuttosto alto).

PHP può essere configurato per mantenere le sessioni tramite riscrittura degli URL, invece dei cookie. (How it's good or bad (< - vedi ad esempio il commento più in alto lì) è un separate question, passiamo ora a quello corrente, con una sola nota a margine: il problema più evidente nelle sessioni basate su URL: la sfacciata visibilità del nudo ID sessione - non è un problema con le chiamate interne Ajax, ma poi, se è attivato per Ajax, è attivato anche per il resto del sito, quindi ...)

In caso di sessioni senza cookie) URL-riscrittura (, le chiamate Ajax deve prendersi cura di loro stessi che loro URL di richiesta siano correttamente realizzati. (Oppure si può rotolare la vostra soluzione personalizzata Si può anche ricorrere a sessioni di mantenimento on the client side, nei casi meno impegnativi.). Il punto è il cura esplicito necessaria per la continuità della sessione, se non si utilizza i cookie:

  1. Se l'Ajax chiama solo estratto URL dal codice HTML (come ricevuto da PHP), che dovrebbe essere OK, in quanto sono già cotti (umm, cookified).

  2. Se hanno bisogno di assemblare URI di richiesta, è necessario aggiungere manualmente l'ID di sessione all'URL. (Controllare here, o le fonti di pagine generate da PHP (with URL-rewriting on) per vedere come farlo.)


Da OWASP.org:

In effetti, l'applicazione web può utilizzare sia meccanismi, cookie o parametri URL o anche passare da uno all'altro (riscrittura automatica dell'URL ) se vengono soddisfatte determinate condizioni (ad esempio, l'esistenza di di client Web senza c supporto ookies o quando i cookie non sono accettato a causa di problemi di privacy degli utenti).

da un post Ruby-forum:

Quando si utilizza il PHP con i biscotti, l'ID di sessione verrà automaticamente inviato nelle intestazioni di richiesta anche per Ajax XMLHttpRequests. Se si utilizza o consente sessioni di php basate su URL , è necessario aggiungere l'ID di sessione a ogni URL di richiesta Ajax.

+0

Qualche statistica affidabile su quante persone hanno disabilitato i cookie _session_? (Non sono riuscito a trovarlo. Solo su Javascript: sembra circa il 2% in USA/Europa e ~ 1,2% media mondiale) –

+0

Gli ID di sessione sull'URL sono obsoleti, [non sicuri] (http: //security.stackexchange. com/questions/14093/why-is-passing-the-session-id-as-url-parameter-insecure) pratica. Nel web di oggi, nessuno dovrebbe presumere che possano navigare con i cookie disabilitati e accedere ancora ai siti Web in cui sono presenti un account. Se uno dei tuoi visitatori ha disabilitato i cookie, è probabilmente sicuro che a) in particolare non vogliono essere in grado di accedere a qualsiasi sito per motivi di privacy; oppure b) l'hanno fatto accidentalmente e ora non possono accedere a * nessun * sito, non solo al tuo. – thomasrutter

+0

La disabilitazione dei cookie può essere rara, ma questa è la risposta giusta. –

Problemi correlati