- Token di autenticità non valido dopo la distribuzione

Question

Utilizziamo EngineYard Cloud per distribuire l'applicazione Ruby on Rails. Stiamo eseguendo Rails v2.3.3.

EngineYard Cloud distribuisce alle istanze AWS in modo simile a Capistrano. Dopo ogni distribuzione, stiamo eseguendo errori di token di autenticità non validi. In particolare, qualsiasi utente che ha precedentemente visitato la nostra applicazione e quindi visita dopo la distribuzione e quindi tenta di inviare un modulo riceve un errore di token di autenticità non valido. Questo errore persiste fino a quando non ripristinano i loro cookie per il sito. Dopo aver ripristinato i loro cookie, il sito funziona come previsto senza errori.

Stiamo utilizzando il negozio di sessione di ActiveRecord e le sessioni vengono salvate nel database.

Questo è l'errore che stiamo vedendo:

ActionController :: InvalidAuthenticityToken /usr/lib/ruby/gems/1.8/gems/actionpack-2.3.3/lib/action_controller/request_forgery_protection.rb: 79: in `verify_authenticity_token'

l'oggetto della sessione è pari a zero dopo l'implementazione, tuttavia, i dati della sessione persiste ancora nel database e l'ID del cookie di sessione esiste ancora:

Sessione:

• Session ID: nil
• dati: nil

non siamo stati in grado di spiegare questo. Qualche idea su quale potrebbe essere la causa principale?

Grazie per eventuali suggerimenti!

---

MODIFICA: solo per aggiornare su questo, siamo stati in grado di isolare un esempio dell'errore.

1) carichi di utenti formano 2) Codice viene aggiornato sul server di 3) l'utente invia modulo ** errore non valido autenticità provvisoria si verifica

Sembra che quando cambia l'ambiente, Rails è in grado di gestire questo con il token di autenticità.

Abbiamo provato diversi passaggi per risolvere:

• Ripristino della sessione
• Eliminazione del cookie di sessione (sia in JavaScript e Rails)
• Pulendo la tabella di sessione nel database dopo la distribuzione del codice

Niente funziona. L'unica cosa che funziona è che l'utente cancelli i cookie dal lato client.

(Siamo stati su Google (anche provato Binging!) Per le risposte, ma senza dadi.Questo sembra essere un problema simile: http://railsforum.com/viewtopic.php?id=21479)

Inoltre: inizialmente pensavamo che fosse isolato per la nostra implementazione su EngineYard, ma siamo anche riusciti a riprodurlo sul nostro server di sviluppo che distribuiamo su via Capistrano.

Qualsiasi pensiero sarebbe accettato con gratitudine.

Grazie!

Answer 1

RISPOSTA: Dopo un lungo lavoro di EngineYard (sono fantastici!) Sono stati in grado di diagnosticare il problema. La causa principale di questo problema è un bug con cluster ibridi. Mongrel sembra non vedere la prima richiesta dopo essere stata avviata.EngineYard ha fatto un ampio lavoro per diagnosticare questa:

non sembra essere nulla nel codice che causa il problema e ho trovato persone al di fuori del nostro ambiente che hanno sperimentato il bug così (http://www.thought-scope.com/2009/07/mongrelcluster-rails-23x-bad-post.html). Suppongo che molte persone non lo vedano perché la prima richiesta di un sito in genere non è un post o la cancellano con i pifferi.

[Esiste una soluzione alternativa che utilizza CURL.] L'arricciatura del lavoro farebbe una semplice richiesta GET a ciascuno dei vostri bastardi sul server per innescarli per così dire. Puoi farlo con capistrano, ma questo non funzionerà se ti schieri tramite la dashboard. È possibile trovare una breve sezione sui ganci di schieramento abbiamo costruito nell'infrastruttura qui: https://cloud-support.engineyard.com/faqs/overview/getting-started-with-engine-yard-cloud

L'aggiunta di una semplice corsa ricciolo http://localhost:500x>/dev/null dovrebbe funzionare (dove x è la porta che avete 5.000-50.005 sul vostro attuale impostare).

Abbiamo risolto il problema spostando il nostro stack da Mongrel a Passenger, ma a quanto pare una riparazione per Mongrel è in lavorazione. Speriamo che questo aiuti qualcuno che vede questo stesso strano problema.

Answer 2

Il token di autenticità è un campo nascosto nel modulo che controlla i binari quando il modulo viene inviato per garantire che i dati dei post provengano da una sessione live.

È presente una misura di sicurezza per impedire alle persone malintenzionate di utilizzare un modulo di invio sul proprio sito per pronunciare un'azione di eliminazione sull'account di qualcuno.

È possibile disattivarlo su tutto l'app aggiungendo questo ai config/environment.rb

config.action_controller.allow_forgery_protection = false 

È possibile disattivarlo un unico controller utilizzando

skip_before_filter :verify_authenticity_token 

o accenderlo

protect_from_forgery :except => :index 

consulta i documenti ActionController::RequestForgeryProtection::ClassMethods per ulteriori dettagli

Answer 3

Sembra che la chiave segreta utilizzata per l'autenticazione stia cambiando durante la ridistribuzione, invalidando tutte le sessioni esistenti.

Avete il parametro di configurazione config.action_controller.session impostato ovunque, e se lo fate, c'è qualcosa che potrebbe causarne la modifica durante la ridistribuzione?

Una delle mie app lo ha configurato in config/environment.rb e uno più recente (generato con Rails 2.3) lo ha impostato in config/initializers/session_store.rb. L'impostazione appare come:

config.action_controller.session = { 
    :secret  => 'long-string-of-hex-digits' 
    } 

Se non si dispone di questo configurato per qualche ragione, rake secret genererà una chiave per voi, che possono poi essere inserito nella propria configurazione.

(Se è — e non è in corso di modifica da parte della distribuzione di processi — allora non ho idea di cosa stia succedendo.)

Answer 4

non sono mai andato a qualsiasi lunghezza per capire i dettagli, ma per me , questo è un problema di decompressione dei dati lato client. Se ho fatto confusione con il modo in cui memorizzo le mie sessioni (e quindi i dettagli della mia autorizzazione,) ottengo questo errore di tanto in tanto. Cancellare i dati del browser privato; biscotti, sessioni autenticate, le opere, l'ho sempre risolto per me.

Spero che questo aiuti.

Answer 5

Se fosse solo per bastardi! Ricevo lo stesso identico errore anche per il passeggero (l'utente carica form, distribuisce, invia -> token di autenticità non valido). Sarebbe interessante sapere come hai risolto il problema passando al passeggero? Ogni ulteriore suggerimento è altamente benvenuto. Darei un'occhiata più da vicino ...

Cheers!

Answer 6

Si è verificato lo stesso problema con Rails 2.3 e un cluster Mongrel in cui il segreto della sessione è definitivamente impostato nell'inizializzatore della sessione. Il problema si è verificato anche dopo aver cancellato i cookie del client sul client.

Tuttavia il suggerimento di fare una richiesta di arricciatura su tutti i bastardi dopo il riavvio sembra funzionare - grazie a dio qualcuno l'ha capito perché sembra dannatamente oscuro.

Le uniche informazioni aggiunte che posso fornire sono l'utilizzo di Apache mod_proxy_balancer insieme a https di fronte ai nostri Mongrels, tuttavia questo problema si verificava prima di attivare SSL. Qualcuno sta vedendo questo con haproxy come il bilanciatore invece di Apache?

Answer 7

Questo risolto questo problema per me :-) :-) :-)

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4690-mongrel-doesnt-work-with-rails-238#ticket-4690-37 Pubblicato da Mike Bethany 30 agosto 2010 @ 18:43.