Szyny 3 token autentyczności żądania AJAX zignorowany

Question

Rails wydaje się ignorować tokeny autentyczności dla żądań AJAX. Na przykład celowo zmieniłem wywołanie AJAX, aby przetestować to przy użyciu nieprawidłowego tokena, a żądania wyglądają na normalne.

Aplikacja ma domyślną konfigurację do przechowywania plików cookie sesji i ma funkcję protect_from_forgery w ApplicationController.

Jakieś pomysły, czego jeszcze mogłem nie mieć?

Answer 1

EDIT >> Zamieściłem tę odpowiedź w blogu, a także: http://zadasnotes.blogspot.com/2010/11/rails-3-forgery-csrf-protection-for.html

EDIT 2 >> ta została zmieniona w Rails 3.0.4. Zobacz śledzić post tutaj: http://zadasnotes.blogspot.com/2011/02/rails-forgery-csrf-protection-for-ajax.html

Po zbadaniu go przez jakiś czas, postanowiłem wykopać trochę do dokumentacji kodu szyny, aby dowiedzieć się.

Począwszy tutaj: http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection.html#method-i-form_authenticity_token

protect_from_forgery dodaje before_filter na verify_authenticity_token który znajduje się poniżej:

# File actionpack/lib/action_controller/metal/request_forgery_protection.rb, line 95 
95:  def verify_authenticity_token 
96:   verified_request? || raise(ActionController::InvalidAuthenticityToken) 
97:  end 

a verified_request? pokazany jest tutaj:

# File actionpack/lib/action_controller/metal/request_forgery_protection.rb, line 
104:  def verified_request? 
105:   !protect_against_forgery? || request.forgery_whitelisted? || 
106:   form_authenticity_token == params[request_forgery_protection_token] 
107:  end 

Wreszcie request.forgery_whitelisted?:

# File actionpack/lib/action_dispatch/http/request.rb, line 126 
126:  def forgery_whitelisted? 
127:  get? || xhr? || content_mime_type.nil? || !content_mime_type.verify_request? 
128:  end 

Wskazówka XHR?. xmlHttpRequest jest na białej liście i nie znajduje się na liście protect_from_forgery. Wygląda więc na to, że jest to zgodne z projektem.

Po dalszych badaniach xmlHttpRequests wydaje się, że istnieją ograniczenia dotyczące ich uruchamiania w różnych domenach, co powoduje, że nie jest konieczne stosowanie sprawdzania csrf w dniu xhr.