Intermittente 403 a causa di errore CSRF (Django 1.2.3)

Question

Ho un bug un po 'folle/esasperante con un sito e CSRF.

Stiamo eseguendo Django 1.2.3, Python 2.6 su Ubuntu con Apache2 + mod_wsgi e abbiamo riscontrato che gli utenti finali hanno segnalato 403 errori di verifica CRSF e 403 come risultato.

Tutte le nostre forme hanno un csrf_token e - per quanto ne so - le cose funzionano bene in dev locale e sul palco (non siamo ancora in produzione) ... a parte per un ufficio (il cliente, natch). In occasioni casuali, ottengono un tale 403, ma poi si aggiornano e andrà via (quindi non è l'HTML privo di un token ecc.)

Sto riflettendo su cause e soluzioni, e potrebbe essere che quello office ha una cache proxy diabolicamente eccessiva o mal configurata, o simile, e apprezzerebbe alcuni suggerimenti su cosa possiamo fare, in un modo Django/Apache per gestire i proxy over-the-top (l'ufficio del cliente probabilmente vince cambiare la loro configurazione) o cosa altro potrebbe fare per far fallire questi CSRF.

BTW: questo era un progetto 1.2.3 da zero, non una sorta di 1,1 aggiornamento, e usiamo solo il singolo standard/csrf_tokens corretta 1.2.3 CSRFMiddleware e manualmente aggiunto - non il CSRFResponseMiddleware includere automaticamente il csrf_token

Inoltre: questo è accaduto su due server separati (server di sviluppo e server di staging), che sono ospitati in posizioni separate. I fattori comuni sono (in teoria) lo stesso setup di Django/Apache/mod_wsgi, lo stesso codebase e lo stesso ufficio che ottiene gli 403 (e non è in grado di replicare gli 403 nella propria posizione).

Answer 1

solo un aggiornamento nel caso in cui aiuti chiunque.

Abbiamo abbandonato la protezione CRSF per testare (utilizzando http://johnmc.co/llum/disable-csrf-protection-for-django-1-2/). Questo ha chiarito i 403, ma poi abbiamo avuto 500 intermittenti per i dati POST a lunghezza zero dalla stessa rete client/locale, che spiegava che il CSRF falliva perché il token era presente nella sessione ma non nel payload (piuttosto che il altro modo).

Quindi, non era un problema CSRF, in particolare, ma un problema POST-payload-getting-zapped-somewhere. (Molto probabilmente da un proxy mal configurato in una sola posizione)

HTH

Steve