1

So in my Rails 4.0 app, I'm using Devise for my authentication management and I've noticed that I get a 500 error when I try to log out of an expired session. I'm not sure where the problem is located though. I see a number of different potential sources:

1) I don't completely understand how the authenticity token is validated, but my understanding is that it comes from something in the session store. In this case, my session store is configured as follows:

*config/initializers/session_store.rb*

MyApp::Application.config.session_store ActionDispatch::Session::CacheStore, :expire_after => 20.minutes

When I log out and receive this error, the 20 minutes has passed, so my session should be expired in the cache. I don't want to increase this number though just to be able to log out of my session. That doesn't seem to make much sense.

2) The other possibility is in the config for Devise. I'm using the default settings for the Devise Timeoutable module, show below.

config/initializers/devise.rb

# ==> Configuration for :timeoutable
# The time you want to timeout the user session without activity. After this
# time the user will be asked for credentials again. Default is 30 minutes.
config.timeout_in = 30.minutes

# If true, expires auth token on session timeout.
config.expire_auth_token_on_timeout = false

I would assume that Devise would be smart enough to check if the token is already expired and just pass me through if yes. Otherwise, its trying to destroy a nil session, which again doesn't make any sense.

3) The final possibility is in the Devise session controller itself. Perhaps I need to put something like:

skip_before_filter :verify_authenticity_token, :only => [:destroy]

I would assume that would work, but it feels like a hack to me given that Devise is such a well used gem and I can't be the only person who is doing this. If I need to do this, I would assume I'm doing something else wrong.

Has any one else run into this issue? I've only encountered this problem since upgrading to Rails 4.0 (Running Devise 3.2.2). I didn't have this problem with Rails 3.2 (Running Devise ~> 3.1.0).

I'm mostly just trying to avoid my users seeing a Server 500 error when they try to log out of an unattended session and I'm looking for the "proper" way to handle it. Any ideas?

R. Yanchuleff
  • 323
  • 1
  • 15

2 Answers2

1

i'm having the same issue (but it started just after trying my application with IE...just a case, but who knows ahahah).

I ended up adding an hidden field to all the forms for creating and destroying sessions because since then i often get that problem (mostly if i create a session for my different models - users and admins) and it seems to work, even though it seems a hack to me also.

<%= tag(:input, :type => "hidden", :name => request_forgery_protection_token.to_s, :value => form_authenticity_token) %>

Anyway i preferred this solution to skipping filter in application controller. Check also this question: Rails 4 Authenticity Token

hope it helps

Community
  • 1
  • 1
sissy
  • 2,908
  • 2
  • 28
  • 54
  • I appreciate the feedback. In my case, I'm not submitting a form though. I'm just calling a link with method type DELETE. I suppose I could switch it over to a form but thats alot of overhead. From the post you linked I'm trying switching my application_controller.rb to use `protect_from_forgery with: :null_session` instead of `:exception`. Perhaps that will resolve my issue, not sure what I'm giving up in security by making that change though. – R. Yanchuleff Mar 13 '14 at 15:45
  • Theoretically it shouldn't be a security issue changing to :null_session, but it's mostly for API calls. You should give it a try cause it's quite disappointing exception. – sissy Mar 13 '14 at 15:54
  • 2
    So that fixed the issue, changing it to :null_session no longer causes it to throw the authenticity token exception. – R. Yanchuleff Mar 14 '14 at 02:39
0

Add in your application controller

protect_from_forgery with: :reset_session

Rahul Sharma
  • 1
  • 2