Perché il metodo .ajax () di jquery non invia il mio cookie di sessione?

Dopo aver effettuato l'accesso tramite $.ajax()un sito, sto cercando di inviare un secondo$.ajax() richiesta a quel sito, ma quando controllo le intestazioni inviate utilizzando FireBug, nella richiesta non viene incluso alcun cookie di sessione.

Che cosa sto facendo di sbagliato?

Le chiamate AJAX inviano i cookie solo se l'URL che stai chiamando si trova nello stesso dominio dello script chiamante.

Questo potrebbe essere un problema tra domini.

Forse hai provato a chiamare un URL www.domain-a.commentre lo script di chiamata era attivo www.domain-b.com(in altre parole: hai effettuato una chiamata tra domini nel qual caso il browser non ha inviato alcun cookie per proteggere la tua privacy).

In questo caso le tue opzioni sono:

• Scrivi un piccolo proxy che risiede sul dominio-b e inoltra le tue richieste al dominio-a. Il tuo browser ti permetterà di chiamare il proxy perché si trova sullo stesso server dello script chiamante.
  Questo proxy può quindi essere configurato da te per accettare un nome cookie e un parametro valore che può inviare al dominio-a. Ma per far funzionare tutto questo è necessario conoscere il nome del cookie e valutare il proprio server sul dominio-a vuole l'autenticazione.
• Se stai recuperando oggetti JSON, prova invece a utilizzare una richiesta JSONP . jQuery supporta questi. Ma devi modificare il tuo servizio sul dominio, in modo che restituisca risposte JSONP valide.

Sono contento che ciò abbia aiutato anche un po '.

Opero in uno scenario interdominio. Durante l'accesso, il server remoto restituisce l'intestazione Set-Cookie insieme a Access-Control-Allow-Credentialsset su true.

La prossima chiamata ajax al server remoto dovrebbe utilizzare questo cookie.

CORS Access-Control-Allow-Credentialsè lì per consentire la registrazione tra domini. Controlla https://developer.mozilla.org/En/HTTP_access_control per esempi.

Per me sembra un bug in JQuery (o almeno una funzionalità nella prossima versione).

AGGIORNARE:

1. I cookie non vengono impostati automaticamente dalla risposta AJAX (citazione: http://aleembawany.com/2006/11/14/anatomy-of-a-well-designed-ajax-login-experience/ )

   Perché?

2. Non è possibile ottenere il valore del cookie dalla risposta per impostarlo manualmente ( http://www.w3.org/TR/XMLHttpRequest/#dom-xmlhttprequest-getresponseheader )

   Non ho capito bene..

   Dovrebbe esistere un modo per chiedere jquery.ajax()di impostare il XMLHttpRequest.withCredentials = "true"parametro.

RISPOSTA: è necessario utilizzare il xhrFieldsparametro http://api.jquery.com/jQuery.ajax/

L'esempio nella documentazione è:

$.ajax({
   url: a_cross_domain_url,
   xhrFields: {
      withCredentials: true
   }
});

È anche importante che il server risponda correttamente a questa richiesta. Copia qui i grandi commenti di @ Frédéric e @Pebbl:

Important note: when responding to a credentialed request, server must specify a domain, and cannot use wild carding. The above example would fail if the header was wildcarded as: Access-Control-Allow-Origin: *

Quindi quando la richiesta è:

Origin: http://foo.example
Cookie: pageAccess=2

Il server dovrebbe rispondere con:

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Credentials: true

[payload]

Altrimenti il ​​payload non verrà restituito allo script. Vedi: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS#Requests_with_credentials

utilizzando

xhrFields: { withCredentials:true }

come parte della mia chiamata ajax jQuery era solo una parte della soluzione. Avevo anche bisogno di avere le intestazioni restituite nella risposta OPTIONS dalla mia risorsa:

Access-Control-Allow-Origin : http://www.wombling.com
Access-Control-Allow-Credentials : true

Era importante che solo una consentisse "origine" era nell'intestazione della risposta della chiamata OPTIONS e non "*". Ho raggiunto questo obiettivo leggendo l'origine della richiesta e inserendola nuovamente nella risposta, probabilmente eludendo il motivo originale della restrizione, ma nel mio caso d'uso la sicurezza non è fondamentale.

Ho pensato che valesse la pena menzionare esplicitamente il requisito di una sola origine, poiché lo standard W3C consente un elenco separato da spazi, ma Chrome no! http://www.w3.org/TR/cors/#access-control-allow-origin-response-header NB il bit "in pratica".

Metti questo nella tua funzione init:

$.ajaxSetup({
  xhrFields: {
    withCredentials: true
  }
});

Funzionerà.

Ci sono già molte buone risposte a questa domanda, ma ho pensato che potrebbe essere utile chiarire il caso in cui ti aspetteresti che il cookie di sessione venga inviato perché il dominio del cookie corrisponde, ma non viene inviato perché la richiesta AJAX è essere creato per un sottodominio diverso. In questo caso, ho un cookie assegnato al dominio * .mydomain.com e desidero che sia incluso in una richiesta AJAX a different.mydomain.com ". Per impostazione predefinita, il cookie non viene inviato. Non è necessario disabilitare HTTPONLY sul cookie di sessione per risolvere questo problema. È sufficiente fare ciò che il wombling ha suggerito ( https://stackoverflow.com/a/23660618/545223 ) e procedere come segue.

1) Aggiungi quanto segue alla tua richiesta Ajax.

xhrFields: { withCredentials:true }

2) Aggiungi quanto segue alle intestazioni di risposta per le risorse nel sottodominio diverso.

Access-Control-Allow-Origin : http://original.mydomain.com
Access-Control-Allow-Credentials : true

Dopo aver provato le altre soluzioni e ancora non riuscendo a farlo funzionare, ho scoperto quale fosse il problema nel mio caso. Ho cambiato contentType da "application / json" a "text / plain".

$.ajax(fullUrl, {
    type: "GET",
    contentType: "text/plain",
    xhrFields: {
         withCredentials: true
    },
    crossDomain: true
});

Stavo avendo lo stesso problema e facendo alcuni controlli il mio script non stava semplicemente ricevendo il cookie sessionid.

Ho scoperto osservando il valore del cookie sessionid nel browser che il mio framework (Django) stava passando il cookie sessionid con HttpOnly come predefinito. Ciò significava che gli script non avevano accesso al valore sessionid e quindi non lo passavano insieme alle richieste. È ridicolo che HttpOnly sia il valore predefinito quando così tante cose usano Ajax che richiederebbe restrizioni di accesso.

Per risolvere questo problema ho modificato un'impostazione (SESSION_COOKIE_HTTPONLY = False) ma in altri casi potrebbe essere un flag "HttpOnly" sul percorso del cookie

Se stai sviluppando localhosto una porta su localhost come localhost:8080, oltre ai passaggi descritti nelle risposte sopra, devi anche assicurarti di non passare un valore di dominio nell'intestazione Set-Cookie.
Non è possibile impostare il dominio su localhostnell'intestazione Set-Cookie - non è corretto - è sufficiente omettere il dominio.

Vedi Cookie su localhost con dominio esplicito e Perché asp.net non crea cookie in localhost?

Solo i miei 2 centesimi sull'impostazione del problema con i cookie PHPSESSID su localhost e in ambiente di sviluppo. Eseguo la chiamata AJAX al mio endpoint API REST sul locahost. Supponiamo che il suo indirizzo sia mysite.localhost/api/member/login/(host virtuoso nel mio ambiente di sviluppo).

• Quando faccio questa richiesta su Postman , le cose vanno bene e PHPSESSID è impostato con la risposta.

• Quando richiedo questo endpoint tramite AJAX dalla pagina proxy di Browsersync (ad es. Dalla 122.133.1.110:3000/test/api/login.phpriga dell'indirizzo del mio browser, vedo che il dominio è diverso rispetto a mysite.localhost) PHPSESSID non viene visualizzato tra i cookie.

• Quando faccio questa richiesta direttamente dalla pagina sullo stesso dominio (cioè mysite.localhost/test/api/login.php) PHPSESSID è impostato correttamente.

Quindi si tratta di un problema relativo ai cookie di richiesta di origine incrociata, come indicato nella risposta @flu sopra

Aggiungere il mio scenario e la mia soluzione nel caso in cui aiuti qualcun altro. Ho riscontrato un caso simile durante l'utilizzo delle API RESTful. Il mio server Web che ospita file HTML / Script / CSS e il server delle applicazioni che espongono le API sono stati ospitati sullo stesso dominio. Tuttavia, il percorso era diverso.

web server - miodominio / pagine web /abc.html

usato abc.js che imposta cookie chiamato mycookie

server app - miodominio / webapis / nome servizio.

a cui sono state fatte le chiamate API

Mi aspettavo il cookie in miodominio / webapis / nome servizio e ho provato a leggerlo ma non è stato inviato. Dopo aver letto il commento dalla risposta, ho verificato nello strumento di sviluppo del browser che il percorso di mycookie era impostato su "/ pagine web " e quindi non disponibile nella chiamata di servizio a

miodominio / webapis / nome servizio

Quindi durante l'impostazione dei cookie da jquery, questo è quello che ho fatto -

$.cookie("mycookie","mayvalue",{**path:'/'**});

Forse non rispondevo al 100% alla domanda, ma mi sono imbattuto in questo thread nella speranza di risolvere un problema di sessione durante la pubblicazione di un fileupload dal gestore delle risorse dell'editor innovastudio. Alla fine la soluzione era semplice: hanno un flash-uploader. Disabilitando quello (impostazione

var flashUpload = false;   

in asset.php) e le luci hanno ricominciato a lampeggiare.

Dato che questi problemi possono essere molto difficili da debug, ho scoperto che mettere qualcosa di simile nel gestore del caricamento ti metterà sulla strada giusta (beh, io in questo caso):

$sn=session_name();
error_log("session_name: $sn ");

if(isset($_GET[$sn])) error_log("session as GET param");
if(isset($_POST[$sn])) error_log("session as POST param");
if(isset($_COOKIE[$sn])) error_log("session as Cookie");
if(isset($PHPSESSID)) error_log("session as Global");

Un tuffo nel registro e ho individuato rapidamente la sessione mancante, dove non è stato inviato alcun cookie.