Se avessi un utente collegato al mio sito, con il suo ID memorizzato $_SESSIONe dal suo browser, avrebbe fatto clic su un pulsante "Salva" che avrebbe fatto una richiesta AJAX al server. I suoi $_SESSIONe i cookie verranno conservati in questa richiesta e posso fare affidamento sull'id che è presente nella $_SESSION?
Risposte:
La risposta è si:
Le sessioni sono gestite 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 consapevole di ciò che accade, funziona esattamente come fa con le richieste regolari.
Warning: session_write_close(): Failed to write session data (user)errore in un progetto, ma solo quando la richiesta AJAX si verifica durante il caricamento del resto della pagina. Sto usando un database MySQL per i dati della sessione ed è possibile che la richiesta della pagina principale stia bloccando quella tabella, impedendo alla richiesta AJAX di accedervi.
Se il file PHP che ha le richieste AJAX ha session_start()le informazioni sulla sessione verranno conservate. (escludendo le richieste sono all'interno dello stesso dominio)
Quello che stai veramente ottenendo è: vengono inviati i cookie con la richiesta AJAX? Supponendo che la richiesta AJAX sia rivolta allo stesso dominio (o all'interno dei vincoli di dominio del cookie), la risposta è sì. Quindi le richieste AJAX allo stesso server mantengono le stesse informazioni sulla sessione (supponendo che gli script chiamati emettano session_start () come per qualsiasi altro script PHP che desidera accedere alle informazioni sulla sessione).
Beh, non sempre. Usando i cookie, sei bravo. Ma il "posso fare affidamento sull'id presente in modo sicuro" mi ha spinto a estendere la discussione con un punto importante (soprattutto per riferimento, poiché il conteggio dei visitatori di questa pagina sembra abbastanza alto).
PHP può essere configurato per mantenere le sessioni mediante la riscrittura degli URL, anziché i cookie. ( Quanto è buono o cattivo (<- vedi ad esempio il commento più in alto) è una domanda separata , ora atteniamoci a quella attuale, con una sola nota a margine: il problema più importante con le sessioni basate su URL - il palese visibilità dell'ID sessione nuda - non è un problema con le chiamate Ajax interne; ma poi, se è attivato per Ajax, è attivato anche per il resto del sito, quindi lì ...)
In caso di sessioni di riscrittura degli URL (senza cucina), le chiamate Ajax devono occuparsi da sole che i loro URL di richiesta siano realizzati correttamente. (Oppure puoi creare la tua soluzione personalizzata. Puoi persino ricorrere a mantenere sessioni sul lato client , in casi meno impegnativi.) Il punto è la cura esplicita necessaria per la continuità della sessione, se non usi i cookie:
Se le chiamate Ajax estraggono gli URL alla lettera dall'HTML (come ricevuto da PHP), ciò dovrebbe essere OK, poiché sono già cotti (umm, cookified).
Se devono assemblare da soli gli URI di richiesta, l'ID sessione deve essere aggiunto manualmente all'URL. (Controlla qui , o le fonti di pagina generate da PHP ( con la riscrittura degli URL attiva ) per vedere come farlo.)
Da OWASP.org :
In effetti, l'applicazione Web può utilizzare entrambi i meccanismi, i cookie o i parametri URL o persino passare dall'uno all'altro (riscrittura automatica dell'URL) se vengono soddisfatte determinate condizioni (ad esempio, l'esistenza di client Web senza supporto dei cookie o quando i cookie non lo sono accettato a causa di problemi di privacy dell'utente).
Da un post sul forum di Ruby :
Quando si utilizza php con i cookie, l'ID sessione verrà automaticamente inviato nelle intestazioni della richiesta anche per Ajax XMLHttpRequests. Se usi o permetti sessioni php basate su URL, dovrai aggiungere l'id di sessione a ogni URL di richiesta Ajax.
È molto importante che le richieste AJAX mantengano la sessione. L'esempio più semplice è quando provi a fare una richiesta AJAX per il pannello di amministrazione, diciamo. Naturalmente proteggerai la pagina a cui fai la richiesta, non accessibile da altri che non hanno la sessione che ricevi dopo il login dell'amministratore. Ha senso?
Una cosa a cui prestare attenzione, in particolare se si utilizza un framework, è verificare 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, sebbene ovviamente il resto dei dati in la sessione non sarà interessata.
Se l'applicazione sta rigenerando gli ID di sessione in questo modo, è possibile che si verifichi una situazione in cui una richiesta Ajax in effetti invalida / sostituisce l'ID di sessione nella pagina richiedente.
Questo è ciò che fanno i framework, ad esempio se si inizializza una sessione in Front Controller o script boostrap, non ci si dovrà preoccupare della sua inizializzazione né per i controller di pagina né per i controller ajax. I framework PHP non sono una panacea, ma fanno così tante cose utili come questa!
inserisci la tua session () auth in tutte le pagine del server accettando una richiesta ajax:
if(require_once("auth.php")) {
//run json code
}
// do nothing otherwisequesto è l'unico modo in cui l'ho mai fatto.
HttpOnlyflag quando imposta un cookie, il che significa che il tuo Javascript non sarà in grado di vedere il cookie. Tuttavia, il cookie verrà comunque 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àdocument.cookie.