Il token di stato CSRF non corrisponde a uno SDK PHP FB fornito 3.1.1 Oauth 2.0

Question

I registri del mio server mostrano un errore "token di stato CSRF non corrispondente a uno fornito" che sembra verificarsi per quasi tutti gli utenti. Tuttavia, gli utenti sono creati e/o autenticati e sono in grado di recuperare le informazioni dell'utente. Sto usando un server Linux con Apache. Sto anche usando l'ultimo SDK PHP di Facebook v.3.1.1 Qualcuno può dirmi perché questo sta accadendo e come risolverlo?

Answer 1

Beh, ho incontrato questo problema esatto, una volta, e ho avuto un problema con le state & code parametri nell'URL - il mio file .htaccess non li stava inoltrando.

Immagino che stia avendo lo stesso problema.

CSRF state token does not match one provided

Spero che questo aiuti

Answer 2

ho avuto un problema simile la settimana scorsa, e tracciata verso il basso per il campo state sovrascrittura da più chiamate a getLoginUrl(). Ogni volta che chiami getLoginUrl(), un nuovo token state viene generato nell'SDK e archiviato nello $_SESSION (è solo un valore casuale), quindi se lo chiami due volte e l'utente utilizza il primo collegamento per accedere, la seconda chiamata avrà reimpostare il token interno dell'SDK state e si otterrà questo errore nei registri.

L'SDK cerca lo stesso token state nell'URL che ritorna dopo che Facebook autorizza l'utente e li reindirizza al tuo sito, e se non corrisponde lo registrerà questo errore (ecco un collegamento allo source) .

Answer 3

Per aggiungere un po 'alla risposta di Chesles, questo problema può verificarsi se stai giocando con le funzioni session_start() - session_write_close(), come ho fatto io.

Se non vi è una sessione avviata quando si richiede l'account loginUrl, si otterrà questo errore.

Sidenote: perché preoccuparsi di interrompere la sessione?

Gli script che utilizzano sessioni si interrompono a vicenda, poiché sono in attesa che l'array di sessione sia disponibile per l'uso.

Immagina di avere un'applicazione popolare, con migliaia di utenti, e di avere un'azione (uno script php) in cui pubblichi un'immagine. Qualcosa di simile a questo:

--starting sessione nella parte superiore dello script

--connecting to facebook

--creating l'immagine

--sharing l'immagine con la chiamata API

fine --script, la sessione si chiude automaticamente

In questo modo, la sessione verrà utilizzato dal script per un lungo periodo senza motivo. Fate attenzione con tali script, usare qualcosa come questo, invece: sessione

--starting destra prima in cui si crea l'oggetto facebook

--connecting to facebook

--closing sessione con session_write_close() , disponibili, altri script della matrice sessione può caricare

--creating l'immagine

--sharing l'immagine con la chiamata API/* E credo che questo non ha bisogno di una sessione. */

- fine script, sessione già chiusa manualmente.

Cheers.

Answer 4

Una nota aggiuntiva - sebbene non sia riportata nella documentazione dell'API di Facebook PHP, è necessario che apache sia configurato per le sessioni PHP affinché il processo di login funzioni. Questo si è rivelato essere il problema che abbiamo riscontrato quando stavamo ricevendo il "token di stato CSRF che non corrisponde a quello fornito".

Accertarsi che si stia utilizzando un pool di server configurato per utilizzare memcache per le informazioni sulla sessione, altrimenti apache scriverà le informazioni sulla sessione localmente e se la richiesta successiva non passa allo stesso server si otterrà il "token di stato CSRF non corrisponde a quello fornito".

Questa è una di quelle cose che hanno funzionato come un incantesimo in un ambiente di sviluppo (con un server) ma non sono riuscite nella produzione.

Abbiamo anche dovuto riconfigurare le nostre impostazioni CDN per assicurarci di passare il cookie della sessione PHP.

Answer 5

Ho avuto lo stesso problema nella mia macchina locale e il problema si è rivelato essere il fatto che il mio file host stava bloccando la comunicazione con Verisign, quindi l'URL di Facebook tenta di comunicare con (http://crl.verisign.com/pca3.crl) mai lavorato (stato: 404) .

Commentare i vari indirizzi IP di Verisign dal mio file hosts ha funzionato!

Answer 6

Lo stato e il codice CSRF vengono verificati utilizzando sessioni locali, scommetto che è necessario controllare la sessione.save_handler nel php.ini e se funziona correttamente.

Answer 7

Il codice SDK di Facebook ha un bug durante il controllo di token due volte nello stesso gestore.

ho modificato la funzione di getCode facebook.php come questo:

protected function getCode() { 
    if (!isset($_REQUEST['code']) || !isset($_REQUEST['state']) || $this->state === null) { 
     return false; 
    } 
    if ($this->state === $_REQUEST['state']) { 
     // CSRF state has done its job, so clear it 
     $this->state = null; 
     $this->clearPersistentData('state'); 
     return $_REQUEST['code']; 
    } 
    self::errorLog('CSRF state token does not match one provided.'); 

    return false; 
} 

per essere più chiaro e non indica gettone valido se chiamato due volte.

Per essere chiari la funzione può essere chiamata due volte sullo stesso gestore URL se ad esempio:

$facebook->getUser(); e poi nello stesso gestore $facebook->getLogoutUrl() poi il getCode() è chiamato due volte così risultante in e il messaggio di errore non valido

Answer 8

se usi.htaccess mod reindirizza i reindirizzamenti sulla tua pagina, usa [QSA] (Query String Append) alla fine delle righe per conservare le variabili GET, oppure hai perso la variabile $ code, che è richiesta al login facebook

Answer 9

Ho avuto lo stesso problema. È facile. Non tiratevi chiamare

$fbLoginUrl = $facebook->getLoginUrl(...); 

prima

$fbUser = $facebook->getUser(); 

altrimenti si otterrà "CSRF token di stato non corrisponde a quello fornito" errore.