This project is archived and is in readonly mode.
Rails 2.3.2 sessions problem - active record
Reported by Richard Delph | March 28th, 2009 @ 09:14 PM | in 3.x
Hi everyone, I seem to be having what appears to be a major issue with sessions. I'm running rails 2.3.2, with mysql on mac os x and the problem arose whilst following the prag prog's agile dev with rails book (3rd edition latest release). I change the default session store to use active record, run all the necessary rake tasks to create the sessions migration, run the migration itself and reset the rails mongrel server. Now as soon as an action is called that tries to access the session I receive an InvalidAuthenticityToken error however I can see in my trace that this token is included in the request params. SO... I didn't some hunting around and added the following line to controller the action lies in:
protect_from_forgery :only => [:create, :update, :destroy]
and while this solves the invalidauthenticitytoken error it doesn't solve the invalidauthenticitytoken error when actions in other controllers are called e.g. create/edit/destroy! so eventually I just overrode the lot by adding this to my development.rb env file:
config.action_controller.allow_forgery_protection = false
and this produced some strange results, it seems to create a new session id for each request which I can see whilst monitoring the DB table!
i finally decided to revert to the default cookie store but then started receiving more errors as I filled up the 4kb data limit pretty quickly which is understandable! so this leaves me stumped! is this a problem with the latest rails release or am I completely missing something here?
any help is much appreciated.
kind regards
Richard Delph
Comments and changes to this ticket
-
Richard Delph April 2nd, 2009 @ 03:38 AM
Just wondering if anyone has encountered the same error as described above when using the active record session store?
-
Richard Delph April 2nd, 2009 @ 04:26 AM
With the help of someone else who has encountered this error it seems I just needed to comment out the line
protect_from_forgery
in the application controller and this seemed to have sorted it. though the error still stands with new sessions being created when inserting the line
config.action_controller.allow_forgery_protection = false
in the dev environment file...
Rich
-
ronin-52463 (at lighthouseapp) April 5th, 2009 @ 09:51 AM
I've had the same problem and didn't find any solution.
I think that disabling protections will go around the problem and not solve it.
-
John Smilanick May 18th, 2009 @ 06:20 PM
I have similar session issues under slightly different circumstances. I overloaded render_optional_error_file (called from rescue_action_in_public) and read some data from the session to display custom 500 and 404 layouts based on the session data. No matter what happens after the session is loaded the session gets reset and the user gets logged out (might be caused by a new session_id). Since these are both related to error handling I thought this might be relevant.
-
Robin Wunderlin June 22nd, 2009 @ 04:12 PM
Same problem here.
Looks like the authenticity_token of the form is not saved correctly by the session.
So after submitting the form the comparison of the param value and the session value doesn't work correctly.(Removing "protect_from_forgery" is not a solution) -> I changed to cookies. (Till the problem is solved)
-
Robin Wunderlin June 23rd, 2009 @ 10:28 AM
- Title changed from Rails 2.3.2 sessions problem to Rails 2.3.2 sessions problem - active record
-
windix June 26th, 2009 @ 01:40 AM
I had exactly the same problem here yesterday.
(My environment: ROR 2.3.2, MySQL 5.1.35 on Mac OS X 10.5.7)
I logged authenticity_token and found it changed for each request but the params value submitted by the form still used the old value which caused the problem.
It's the same as Robin Wunderlin mentioned above.
But curiously, I restarted my Mac this morning and it seems works fine now.
-
Mauricio Gomes June 29th, 2009 @ 02:12 PM
I've had the same problem with ActiveRecord sessions and I was skeptical about windix's solution. I rebooted my mac though and my AuthenticityToken problems seemed to have gone away. It doesn't really make sense...
-
Sebastian Nanek July 7th, 2009 @ 11:09 AM
Perhaps trying to use edge rails may help with your problem.
-
Geoff February 25th, 2010 @ 10:55 PM
I appear to be having the same issue in 2.3.4.
App was working fine with cookie store but client requested we switch to active record store and i keep getting ActionController::InvalidAuthenticityToken errors on all form submissions. The authenticity_token is getting sent in the request but apparently is not valid.
I'm seeing sessions get created in the sessions table as well. Very strange.
-
realbite March 16th, 2010 @ 02:33 PM
Had the same problem... new sessions table entry for every request and getting ActionController::InvalidAuthenticityToken. Solved it by just clearing the cookie cache in the Browser.
-
kristian.hellquist (at gmail) September 17th, 2010 @ 11:55 AM
"I'm seeing sessions get created in the sessions table as well. Very strange."
I hade similar problem. When I specified:
ActionController::Base.session_options[:expire_after]=2.years
New sessions weren't created every request.
This might not have anything to do with ActionController::InvalidAuthenticityToken, but maybe helps someone
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>