GET 요청 (JSON 없음) Rails 4.1에서 Devise 3.2.4로 CSRF 토큰 진 본성을 확인할 수 없음

Question

갑자기 나는 heroku에서 내 앱 제작 환경에 더 이상 로그인 할 수 없다. 또는 들어가면 새로운 링크를 클릭하자마자 로그인 화면으로 리디렉션되어 다시 로그인하면 오류가 표시되기 시작합니다.

로그는 다음과 같습니다 (로그인의 경우, 다시 로그인하여 다시 로그인).

내 응용 프로그램의 레이아웃은 CSRF_meta_tags

!!! 
%html 
    %head 
    %title= full_title(yield(:title)) 
    = include_gon(:init => true) 
    = stylesheet_link_tag "application", media: "all" 
    = javascript_include_tag "application" 
    = csrf_meta_tags 
    = render 'layouts/shim' 
    %meta{content: "width=device-width, initial-scale=1.0", name: "viewport"}/ 
    %body.container-fluid 
    #wrapper 
     = render 'layouts/navigation' 
     = render partial: "shared/flash_messages", flash: flash 
     #content 
     = yield 
     = render 'layouts/footer' 
     %br 
     - if request.env['HTTP_USER_AGENT'].downcase.match(/android|iphone|ipad/) 
     - else 
      = debug(params) if Rails.env.development? 
      = debug(@current_user) if Rails.env.development? 

을 포함하고 내 응용 프로그램 컨트롤러는 제외 protect_from_forgery입니다.

class ApplicationController < ActionController::Base 

    # Prevent CSRF attacks by raising an exception. 
    # For APIs, you may want to use :null_session instead. 

    protect_from_forgery with: :exception 

    before_action :authenticate_user! 

end 

그리고 내 경로 파일에서 사용자를 위해 고안했습니다.

devise_for :users, :skip => [:registrations] 
    as :user do 
     get 'users/edit' => 'devise/registrations#edit', :as => 'edit_user_registration' 
     put 'users/:id' => 'devise/registrations#update', :as => 'user_registration' 
    end 

로그 파일은 여기를 참조하십시오.

Started GET "https://stackoverflow.com/users/sign_in" for 58.7.233.232 at 2014-05-16 23:52:48 +0000 
Processing by Devise::SessionsController#new as HTML 
2014-05-16T23:52:48.995008+00:00 heroku[router]: at=info method=GET path=/assets/application-7d1b02fae40091844b4f616c7ec89e83.js host=slapp.herokuapp.com request_id=8f86c336-0bf2-4419-a07d-0c7ecf79cfb4 fwd="58.7.233.232" dyno=web.2 connect=1ms service=2ms status=304 bytes=249 
    Rendered layouts/_shim.html.haml (0.3ms) 
    Rendered devise/sessions/new.html.haml within layouts/application (7.9ms) 
    Rendered layouts/_navigation.html.haml (1.2ms) 
    Rendered shared/_flash_messages.html.haml (0.4ms) 
    Rendered layouts/_footer.html.haml (0.4ms) 

Completed 200 OK in 18ms (Views: 14.1ms | ActiveRecord: 0.0ms) 
2014-05-16T23:52:54.997215+00:00 heroku[router]: at=info method=POST path=/users/sign_in host=slapp.herokuapp.com request_id=6fd107af-4a46-4315-843c-6bbf46827df0 fwd="58.7.233.232" dyno=web.1 connect=7ms service=41ms status=422 bytes=1729 

Started POST "https://stackoverflow.com/users/sign_in" for 58.7.233.232 at 2014-05-16 23:52:54 +0000 
    vendor/bundle/ruby/2.0.0/gems/devise-3.2.4/lib/devise/controllers/helpers.rb:182:in `handle_unverified_request' 

Processing by Devise::SessionsController#create as HTML 
    Parameters: {"utf8"=>"✓", "authenticity_token"=>"o5NFnMmQQGcmNxPhzvFYOF+ThrcO1cY1VdZozvQmtOI=", "user"=>{"email"=>"admin@domain.com", "password"=>"[FILTERED]"}, "commit"=>"Login"} 

Completed 422 Unprocessable Entity in 9ms 

    vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.0/lib/active_support/callbacks.rb:160:in `block in halting' 
    vendor/bundle/ruby/2.0.0/gems/actionpack-4.1.0/lib/action_controller/metal/request_forgery_protection.rb:197:in `verify_authenticity_token' 

    vendor/bundle/ruby/2.0.0/gems/activesupport-4.1.0/lib/active_support/callbacks.rb:166:in `call' 

Can't verify CSRF token authenticity 
ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken): 

    vendor/bundle/ruby/2.0.0/gems/actionpack-4.1.0/lib/action_controller/metal/request_forgery_protection.rb:176:in `handle_unverified_request' 
    vendor/bundle/ruby/2.0.0/gems/actionpack-4.1.0/lib/action_controller/metal/request_forgery_protection.rb:202:in `handle_unverified_request' 

나는 현재 this similar question에 대한 제안과 문제 해결하지만 행운까지하고있다. "protect_from_forgery except : : sign_in"을 시도해 볼 것을 고려하지만 근본 원인을 찾아 낼 수 있다면 불필요한 절충안처럼 보입니다.

Answer 1

나는 하나의 dyno에서 csrf 토큰이 생성되고 다음 http 요청이 두 번째 dyno를 치기 때문에 csrf 토큰이 일치하지 않는다고 생각합니다. csrf 토큰은 데이터베이스에 저장해야하므로 두 dynos에서 공유 할 수 있습니다. 페이지가 제공되고 양식이 처리 될 때 $ DYNO를 쓰십시오. 이렇게하면 어떤 dyno가 csrf 토큰을 처리하고 있는지와 동일한 dyno인지 또는 다른 dyno인지를 보여줍니다.