3

I'm in the process of upgrading a Rails app from Rails 2 directly to Rails 4. I'm using the new /config/initializers/session_store.rb file, with CookieStore, but for some reason my sessions are not saving.

When trying to do something along the lines of render :text => "#{request.session_options[:id]}" I get a new session ID every refresh.

I've tried on different browsers, and all should be accepting cookies.

I have no idea what's going on. Why won't these sessions persist?!

Edit: thank you all for your suggestions. Here's a little more information, and a few things I've noticed:

  • First, about my set up -- I'm running the server with Rails 4/Ruby 2 through RVM on an Ubuntu VM on my Windows 7 machine.
  • Although I'm upgrading from Rails 2, that only really applies to the models/controllers/views/etc -- I generated a new Rails 4 application for all of the supporting infrastructure.
  • I created another application on the same VM that JUST sets a session and then displays, and that works fine.
  • What the session is storing varies slightly depending on what the user is doing, but usually it holds simply a user id (just an integer), and occasionally a little more -- (i first noticed this manifesting itself while trying to pass an OAuth token from the OAuth gem.)
  • I've noticed that if the VM's system clock falls behind the Windows 7 host machine clock, the user id sessions hold. That causes other problems, especially with OAuth, but there seems to just be a time issue somewhere. I've tried doing things like removing the time zone from my environments/development.rb, but that did not help.
Jared
  • 562
  • 1
  • 6
  • 22
  • Can you post the contents of the file. Do you have secret_token defined? Any warning inside rails log? – jurglic Aug 24 '13 at 20:15
  • Sure @jurglic -- the session_store.rb file is `Uplinkr4::Application.config.session_store :cookie_store, key: '_uplinkr4_session'`, and a secret token is defined in secret_token.rb. I see absolutely no warnings (related to this) in my log. – Jared Aug 24 '13 at 20:21
  • Looks right. Have you restarted server after changing those files? And you don't have by any chance disabled cookies in the browser? – jurglic Aug 24 '13 at 20:26
  • Restarted a bunch of times. I initially thought it was a CSRF issue, but I've tried disabling forgery protection to no luck. I'm getting cookies on my browser -- in fact my application's _cookies_ seem to work, it's just the sessions that seem to not save. – Jared Aug 24 '13 at 20:36
  • 1
    Anything suspicious in `rake middleware` output? `use ActionDispatch::Session::CookieStore` should be there. – DNNX Aug 30 '13 at 20:40
  • Are you trying to store more than 4K into the session? – Gonfva Aug 31 '13 at 17:05
  • 1
    @DNNX -- great thought, but nothing weird in `rake middleware` -- and it includes `use ActionDispatch::Session::CookieStore`. – Jared Aug 31 '13 at 19:24
  • @Gonfva -- I thought about switching to ActiveRecord, but it should be far, far less than 4K... – Jared Aug 31 '13 at 19:24
  • OK. Next try. Test with CSRF protection disabled. If it works, enable it again and go for a tank of tea: you have a huge work ahead updating views and controllers. – Gonfva Aug 31 '13 at 21:56
  • After going through and commenting out various lines -- it seems to work or not work based entirely on whether or not the OAuth gem's request token gets added into the session. Theres no reason why that should be anywhere near 4K -- but i think it must be.... – Jared Aug 31 '13 at 23:50
  • If you are writing the request token string, it should use much less than 4K. But if you are storing the request_token object, then bear in mind that the object must be converted into string. – Gonfva Sep 02 '13 at 10:57
  • Thanks, @Gonfva. I sort of mindlessly used the sample code just to test ([here](http://oauth.rubyforge.org/)). I've decided at this point to just dump the gem and roll my own OAuth authentication -- in the end, I think it will just be easier. – Jared Sep 02 '13 at 14:33
  • Have you tried using an alternative session store e.g. `cache_store`? That could provide additional clues. – James Lim Sep 02 '13 at 16:51
  • I've had a similar issue: Session variable was set, then got reset after redirect (session id did not change). Then I read something about a [bug](https://github.com/phusion/passenger/issues/1310) in Cookie Store in Phusion Passenger 5.0.0beta1 (which I had installed), then upgraded my system (`apt-get upgrade`). After that it worked... – lxxxvi Feb 15 '16 at 07:31

3 Answers3

4

As a general answer a couple of possible problems are

  • Session size over 4K limit (which is apparently the case).

    CookieOverflow is raised if you attempt to store more than 4K of data.

Please, bear in mind that if you store an object in session, the object is previously serialized before storing it and its size would be bigger. More info on the general problem and possible solutions for the specific problem, here.

  • Problems with CSRF protection.

    If the security token doesn't match what was expected, the session will be reset

Edit: To check if it is a CSRF case, you can, as Abdo comments below, temporarily disable the protect_from_forgery line in ApplicationController
Gonfva
  • 1,428
  • 16
  • 28
  • My session was being reset and I was completely ignoring "WARNING: Can't verify CSRF token authenticity" in my logs. If you see that in your logs, it's likely the CSRF issue that's deleting your session. – Jeremy Baker Oct 24 '13 at 08:50
  • 3
    In order to see if it's a CSRF thing resetting the session, temporarily comment out the `protect_from_forgery` line in `ApplicationController` – Abdo Mar 23 '15 at 10:58
  • @Gonfva How to solve 'Problems with CSRF protection.' – vidal Jan 16 '17 at 18:43
  • Specific to the case. A general solution could be http://stackoverflow.com/questions/8503447/rails-how-to-add-csrf-protection-to-forms-created-in-javascript – Gonfva Jan 17 '17 at 17:35
2

I had a similar symptoms. It turns out it was because I added the rails-api gem and it totally broke session saving.

hefox
  • 29
  • 2
0

From: Railscasts Episode 415 Upgrading to Rails 4

There’s one more configuration change we need to make, in the secret token initializer. In Rails 4 the configuration option in this file has been renamed from secret_token to secret_key_base. We’ll need to specify both options while we’re transitioning from Rails 3 but once we’ve successfully migrated our application we can remove the secret_token option. It’s best to use a different token for our secret_key_base.

This is necessary because we’re moving from a serialized cookie stored on the client to an encrypted cookie. This prevents users from easily being able to see the contents of their session cookies.

The episode includes a very good series of tips regarding upgrading from 2 to 4 and I was able to do that successfully using this tutorial.

Richard_G
  • 4,700
  • 3
  • 42
  • 78
  • Thanks. I actually have a `secret_key_base` already -- actually, (and I probably should have clarified this earlier), I generated a brand new Rails 4 application, and then am moving my controllers/models/views/helpers/etc into it and debugging accordingly. All references to sessions, as far as I know, are just setting or reading from them -- almost everything configuring sessions should still be defaults from the rails 4 application generator. – Jared Aug 28 '13 at 01:23
  • I went through that very same process on mine as well. The tutorial helped me a lot in that process. – Richard_G Aug 28 '13 at 02:02