This is my first question on StackOverflow! I've searched around and can't seem to find anyone else having this problem, so here goes.
I'm using Ruby on Rails and Devise + OmniAuth to allow people to sign in through Facebook & Google on my site. This works great -- users can sign in and sign out perfectly, so all the routes seem to be working fine.
HOWEVER, occasionally signing out will not work -- it will bring me to a blank page, and upon returning to the website, I'll still be logged in, and there's no way to sign out. If I try opening the site in incognito, or clear my history, it all works again.
I'm guessing the culprit is in the cookies -- it keeps my info so it keeps me logged in even though I want to sign out. I'm a newb at programming though so I'm not sure where to go to fix this.
Thanks for any help!
Turns out it had nothing to do with cookies -- Devise uses https, so if I returned to the page with just http and tried signing out, it would try to do a GET request for the https even though there was none (otherwise it just issues the default DELETE request as normal).
I figured out the answer through this stack overflow question: Devise No route matches [GET] "/users/sign_out" from link with delete specified
I used the first answer by Chris Chattan but there's other ones that might suit you too (you can just use https for everything if you want)
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 have been working on setting up facebook authentication for my rails app and while testing, after logging-in with my facebook account, I keep getting this error:
OAuth2::Error:
{"error":{"message":"This authorization code has been used.","type":"OAuthException","code":100}}
I'm not really sure where to begin with this, but can't seem to find anything else online about it. Any guidance would be appreciated, happy to provide more info if it would be useful.
I had this issue as well. I was seeing the "(facebook) Callback phase initiated." message twice in my Rails logs. It turns out that I was initializing FB authentication twice (I am using Devise and Omniauth-Facebook), and I'm guessing one of these was attempting to reset the access token.
Disabling the initializer in Omniauth-Facebook (config/initializers/omniauth.rb) fixed my issue.
This is due to Facebook changes that have been optional up until now but will roll out 12/5/12 for everyone. From the Developer Roadmap for the Dec '12 breaking changes:
New security restrictions for OAuth authorization codes
We will only
allow authorization codes to be exchanged for access tokens once and
will require that they be exchanged for an access token within 10
minutes of their creation. This is in line with the OAuth 2.0 Spec
which from the start has stated that "authorization codes MUST be
short lived and single use". For more information, check out our
Authentication documentation.
You'll need to update your app to account for this.
Cheers
This bug occurred just after the last facebook push and has been reported to facebook just this morning.
So I guess we just have to wait and, in the meantime, post more details to this report and follow it to both help and solicit facebook folks to solve this issue!
I was incorrectly initializing OmniAuth twice, calling config/initializers/omniauth.rb twice.
This would add OmniAuth::Builder twice to the middleware stack. With recent Facebook changes, this started failing with error 100.
Making sure OmniAuth::Builder got added once I managed to solve this issue.
To double check your middleware stack, run this:
rake middleware
I had the same problem and finally found what was the issue in my case.
So for those, who has this problem and uses just Omniauth without Devise, the root cause of the problem might be in an incorrect route for redirection.
Check you server development.log
Find where it redirects (grep by "Redirected to")
Here is the main point: Check in the log if the callback URL is correct
In my case, in routes.rb I had, for example:
get "mycontroller/home"
which is okay, but in my SessionController I also had:
def create
auth_hash = request.env['omniauth.auth']
user = User.from_omniauth(auth_hash)
session[:user_id] = user.id
redirect_to "mycontroller/home"
end
So I made it working by changing this line in the controller from:
redirect_to "mycontroller/home"
to
redirect_to "/mycontroller/home"
So I was able to work around this. It seems that my application was processing the facebook authentication, then trying to do it a second time and producing this error. Strange since I was trying to redirect to root_url. In any case, changing the page that I was redirecting to from "root_url" to "/" after storing the user info in my database seemed to make all the difference.
I would suggest checking your development log to see if you're getting a similar error.
Trying to use JQuery widgets -- actually JQGrid, in particular -- with a Rails 3 application. I'm using ruby-openid to do authentication with Google, and used Seth Ladd's nice recipe to get that working.
Which it does -- for page views and POSTS from web forms.
However, whenever JQGrid does a POST to update data on the server, two things happen:
Even if the user's browser is already authenticated via logging in to Google, the POST appears to the server as if it were coming from an unauthenticated one, and gets redirected to the OpenID authentication dance. That wouldn't be a showstopper except that
As soon as the server sends back the 401 that's supposed to initiate the redirect-and-authenticate thing, the whole enchilada just stops dead. Normally (as in, say, a POST request from a form submission), the browser sees the 401, reads the enclosed "authenticate over here" info, does the dance, comes back with the session set up, and the cycle continues. But from JQuery/JQGrid...not so much.
Any ideas? I'm confident that I'm missing something obvious here, but I've got one of Rumsfeld's "unknown unknowns" going, I don't know what it is that I'm missing, much less how to fix it! Seems like this should be a long-solved problem, eh?
I could be running afoul of XSS defenses, but if so I've no idea how to proceed other than **-canning the serious investment we've already made in OpenID (including users already signing up & having to furnish/remember passwords -- ick!).
Thanks in advance, my expert colleagues.
(Rails 3.0.7, ruby-openid 2.1.8, JQGrid 3.5.3, JQuery 1.3.2, using Google as the OP so that user never has to type in their identity URL.)
OK, further testing confirms that that's a wrap, ladies and gents.
Of course then I had to figure out how to get the Javascript working with protect_from_forgery, but it turns out that's really easy, you just grab the authenticity token and include it in all Ajax requests, as detailed at http://henrik.nyh.se/2008/05/rails-authenticity-token-with-jquery. Very slick, since this technique automagically builds the token into everything, you don't have to go hunting down all your POST requests.
Oleg, thanks for your help. And I will take your advice.
Thanks too to Sante on the OpenID Code mailing list, who gave me the pointer to the protect_from_forgery header stuff.
While the problem happens almost always to users in Internet Explorer, it has happened in Firefox and Chrome a few times as well.
The issue is in which users attempt to login and either get a 422 error or are simply re-directed back to the login screen. We have a wildcard cookie, but we recently switched it to targeting www (about 3 months ago) and the previous cookie was set to expire at the end of the session.
We also recently switched to Devise authentication from Restful_athentication in hopes that it would fix the issue, but it doesn't seem to be helping. However, I don't see how these are related as they don't really manage the cookies, Rails does, they just put things in the cookies. I thought maybe the issue was that restful-auth was putting something in that got corrupt under weird conditions, but that apparently was not the case at all
UPDATE
After we switched to Devise, users encountering this problem no longer got a 422 error, but now the page just refreshes and nothing happens. I should also mention that when they enter in their email to retrieve their password (as they think they're entering their password in wrong), it returns that the email is not found in the system.
When they clear their cookies, particularly in IE, they still run into the same problem. I've walked a few users through searching for the individual cookies in Firefox and that has solved the problem. However, simply just going to clear cookies the normal way didn't work. The issue was mainly effecting IE7 users, but seems to be all across the map, with users reporting the issue on Chrome, IE8, Firefox, Safari and Safari for the Ipad.
Also, here's a link to the code for the session_store.rb here and here the host is set in def ensure_domain, which is here
UPDATE 2
I just made a very minor adjustment and it changed it so it always sends a host. I tried logging in every different way on every browser and didn't run into any issues. I'm hoping this helps
UPDATE 3 (LAST UPDATE)
We tried a combination of a few different things, so while I'm not exactly sure what fixed it, my best guess is removing the cache from 4 days to when the session ends/browser closes. While I'm not thrilled about this as I personally dislike having to login every time, I'd rather have the problem fixed (and this issue didn't start occurring until after we changed the cache length to 4 days.)
Sending a host was a mistake and actually made the problem worse for everyone as no one was able to login. Another strange thing was that when looking at the cookies created there were two Session ID cookies, which I would guess were causing the conflict, particularly with IE7. Some users are having to clear their cookies to get logged in still, but at least that seems to be working most of the time.
To any having a similar issue, sorry I couldn't be of more help!
If an HTTPS cookie is set to "secure", it WILL NOT be sent out on HTTP protocal. It is as if it doesn't exist. This sounds like what is likely "stripping out" your cookie.
Cookie basics: If something is worth protecting via HTTPS and you need to track that info afterward (ie, authentication token), it is best to keep it in the HTTPS cookie and only access it from HTTPS.
This is a cookie security issue, and is better discussed at: Secure cookies and mixed https/http site usage
Context: A rails app with authlogic for sigup and login
Setup info: Rails 2.3.2
A controller called posts with an action 'show'.
Upon login, I display the posts/index page.
and when the user clicks on an item, item's details get displayed. Fairly standard stuff.
All of this works fine and dandy both in Development and Production (Apache with Passenger 2.2.5 on ubuntu and mysql) EXCEPT for the following problem in one case:
Problem:
ONLY on Firefox/Safari/Chrome (IE7 is Ok) and ONLY in PRODUCTION,
When the user logs in for the very FIRST time in a new session
(open new browser,type in url), the index page is displayed fine
and when an item is clicked, the user gets mysteriously LOGGED OUT
(current_user returns null).
When you login again, everything is BACK to normal - you can logout and login any number of times and no problem - UNTIL you close the browser and start again.
Any other action besides 'show' has the current_user preserved and works fine.
QUESTION:
How is the user session getting lost on a call like this
posts/id only once - the first time ?
The show action doesn't do anything special.
I have used both ActiveRecord Store and Cookies for Session Management with same behavior.
Anybody got any clues, greatly appreciated!
This might be happening because the user is getting redirected from:
http://yoursite.com to http://www.yoursite.com
Here's a blog that mentions this problem:
http://garrickvanburen.com/archive/rails-cookie-settings-for-cross-subdomain-sessions
To paraphrase the blog:
The fix is to set:
config.action_controller.session[:domain] = '.YOURDOMAIN.COM'
inside of environment.rb (Make sure to prefix it with the .). That will make cookies work for both www.yourdomain.com and yourdomain.com (as well as any other subdomains).
This technique is also discussed here:
Losing session in rails 2.3.2 app using subdomain