In Rails 2.3.8 my integration tests (after considerable work, and the help of this post) were able to make use of a single session across requests. In Rails 2.3.10, that functionality broke, and after logging in, subsequent requests have no session.
One possible symptom is that this bit of code used to pass:
open_session do |s|
s.post 'login', :user=>{:user_name=>username, :password=>pass}
assert_not_nil(s.session[:id])
end
And now it fails (s.session[:id] is nil). This may or may not be the problem, as I can confirm that other variables stored in the session during the login action are present. However on subsequent s.post's, the actions all report that there's nothing in the session.
Any advice? I saw one report that Rails 2.3.9 introduced a session bug with this as the workaround, but it doesn't appear to make a difference.
Thanks,
Tom
Did you try s.session.data[:id]
Related
I'm trying to use Wordpress to authenticate my Rails application users with the following Omniauth plugin:
https://github.com/jwickard/omniauth-wordpress-oauth2-plugin
I've followed the instructions carefully, and duplicated his example, but it doesn't work. Which is really surprising, because there's just not that much to it. However, I've found several threads on here like this one, that talk about the same problem I have:
Devise, OmniAuth & Facebook: "Not found. Authentication passthru."
When I click the "Sign in with Wordpress" (which is automatically inserted in my Devise sign-in page), I simply get a 404, with "Not found. Authentication passthru," which is a stub response for the passthru method in the Devise sources. Routes rake just fine, and look like all the examples. I've restarted the server dozens of times.
Despite several attempts to set site: and authorization_url: in the client_options, in both my devise config, and the plugin sources directly, my app never redirects to my Wordpress site. I've got about 10 hours into screwing around with this, and I don't know what's supposed to be responsible for actually sending me to the site to DO the authentication. Further complicating figuring this out is that almost every reference I can find to redirection in this sort of scenario is about the callback to my Rails site, after the authentication is done. I can never get that far.
There's a lot of confusing references to this problem on SO and the internet at large. There's some talk about making a "real" passthru or action_missing method in my OmniauthCallbacksController, but that seems to be outdated information. There's a lot of talk about making sure that I've defined the omniauth_providers in my User model, and I've tried it with and without, but that's not in any of the documentation about this plugin.
I've been trying to look at the plugin's strategy file, and it just doesn't seem that different than other Oauth2 plugins for Facebook, Google, or whatever, that I've been reviewing. It seems like there's a very simple thing I need to set in order to make this all work, but I can't find it, and I've run out of ideas on how to track it down. The plugin was last updated about 5 years ago. Does anyone still use this with modern versions of Devise, Omniauth, and Wordpress? If so, is there a clue you can give me to make it work?
I finally started tracing through the gem, and found where it was failing. As I searched on those further problems, I finally figured out that there were about 25 forks of this gem, and many of them addressed the problem. I used this particular one: https://github.com/bkno/omniauth-wordpress-oauth2-plugin
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.
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
I had a similar symptoms. It turns out it was because I added the rails-api gem and it totally broke session saving.
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.
I've got a Rails 2.3.5 application that I'm migrating to Rails 3.0.10 that's run into a problem with sessions.
Some code is failing during integration tests because the session has no id (request.session is an empty hash, and request.session_options[:id] is nil). We are currently using webrat, but the same thing happens with capybara and with standard rails helpers. Sessions do seem to be set up properly, since some of the integration tests have session ids. It looks like the session id is missing only in tests that don't log in before trying to access the session id (i.e. most of them).
I've tried switching the session backend (it's currently cookie based) to ActiveRecord, but that didn't help. I've created a new Rails 3.0.10 app, and it also has nil session ids. I've even dug into Rails's session handling, and it looks like there's no session id being generated on if a session is missing one.
Is this lack of session ids expected behavior that's documented somewhere? If it's a bug, is there a version of Rails that generates session ids properly?
The only way I've seen how to solve this is to prime the sessions.
sid1 = session[:session_id]
sid2 = request.session_options[:id]
However, if for some reason the session cookie is deleted, it can still happen.
I tried that and no result. I also tried session[:foo] = 'bar' as I liked the way it looked better but still no result.
I rebooted and still no joy. Then I went into my browser settings and deleted my cookies. That fixed it. From this experience it appears a cookie can keep sessions from being forced. I had been changing class names and changing my database tables. Somehow I had corrupted my cookie.
I've got a Rails application running and it seems that every once in a while a user gets the cookie session_id value from a different user.
I use active_record_store to keep track of the session in Rails.
The current_user method:
def current_user
#current_user ||= session[:user_id] ? User.find_by_id(session[:user_id]) : nil
return #current_user
end
I run 8 ruby processes on a Windows machine using Apache 2.2.15. Sometimes it serves the incorrect session_id to the user. My rails version is 2.1.2
In the log file I can see the user changes session_id of a different user.
For instance:
Processing Manage::TruckController#show (for 179.34.103.8 at 2011-05-12 07:35:24) [POST]
Session ID: 1fbc801bbade1007291901ca810bfeda1eab76
....
Completed
And 5 minutes later is would get a different session id, however belonging to a valid user.
Processing Manage::TruckController#edit (for 179.34.103.8 at 2011-05-12 07:40:01) [POST]
Session ID: 2f8e84c40c490c509feabbce9701aa9101ba0f
....
Completed
To me this seems that Rails is handing out incorrect session_id data to the cookie that is stored on the web browser of the user.
Any suggestions on this?
From looking at the code and
the security guide, it seems like there is a slight possibility of MD5 collision. It's very unlikely that this would happen or be reproducible though, so I'm more inclined to say it has something to do with the browser testing.
I'd first make sure that your browser isn't serving up these bad session IDs by using a tool like Charles.
I also recommend using the cookie session whenever possible which would avoid this sort of problem.
Finally, since you're running a fairly old version of Rails it might be worth trying an upgrade. It's possible you're hitting an old bug.
I found this extremely useful.
how-do-i-prevent-rails-users-from-accidentally-authenticating-as-the-wrong-user
If you are:
destroying your database in development
AND
using the out-of-the-box Rails secret_token.rb
The client browser will have preserved a valid session containing a user_id that may or may not belong to that user.
I had a similar issue and resolved it using a code snippet similar to
this comment by mdesantis on managing Rails secret token
I have a rails application which uses the restful_authentication plugin. I have activated the "remember me" functionality but every now and then I am getting logged out. The problem is I can't see the pattern for when it happens.
Sometimes it works in the development environment but not in production. Sometimes it works in Firefox but not in Safari.
Has anyone had similar problems? Also advice on how to test this in a reasonable way would be appreciated (without closing down and reopen the browser all the time).
Are you logging in with multiple PCs/browsers?
The last time I used restful_authentication (which was a while ago) it used a column in your users table to store a remember me token. Logging in with "Remember me" checked on another browser would overwrite the token, effectively invalidating its usage in your first browser.
It's a bit more complicated to set up, but I highly recommend trying out AuthLogic instead.