Rails3 + OpenID == mmmmmm; Rails3 + JQGrid == mmmmmmm; Rails3 + OpenID + JQGrid == BZZZT - ruby-on-rails

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.

Related

Is there a working Devise/Omniauth/Oauth2 interface with Wordpress?

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

RoR - Omniauth - Occassionally cannot sign out - Cookies?

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)

Password protecting pages simply with rails - what should I do?

I'm now on level 7 of Hartl's rails tutorial book and I'm starting to think about my application in deployment. It's an app that allows about 12 social workers to communicate collaboratively and privately. Thus, I need to password protect it.
However, it also needs to be easy to use, very easy to use. A few of these people haven't used a computer before, and having logging on and sign-up processes would put them off completely.
Thus I want to create a landing page, where they have to type a password in (the same password for everybody), then it redirects to the 'discussion pages.' My first idea was to use some obfuscated javascript such that upon typing in the password, it redirects them to the discussion pages, but this doesn't sound very secure.
Can anyone recommend me a better way to do this in rails? Ideally they would only have to type it in once, and then it would authenticate them for all the pages automatically (by setting a cookie?) and anyone trying to access a page directly would be redirected to the authentication page.
Cheers in advance
A very simple authentication option is available to you in this situation. I would suggest you watch the Ruby on Railscast episode 270. I think it just maybe what you are looking for.
If you want really simple, you can use authenticate_or_request_with_http_basic
It's not a replacement for a real authentication system, e.g. Devise or AuthLogic however.
I started to use the lockup gem for this purpose:
https://github.com/gblakeman/lockup
It is super easy to setup and almost every user accessing the site should be able to use it.

No feedback to user on login failure with Rails 3 + Devise + Jquery Mobile

As it says in the subject, I'm just finishing up integrating Devise authentication into a Rails 3.1 app with Jquery Mobile. Most everything here is straight out of the box, no custom code, so there's not a lot I can paste in here to add to the description of the problem.
When a user fails the Sign Up process because of a pre-existing email address, password not long enough, etc., a message is displayed to the user. It isn't pretty, but it at least works.
However when the user has an existing account and types the wrong password during sign in there is no feedback to the user and the console outputs the error:
POST http://localhost:3000/users/sign_in 401 (Unauthorized)
I've got a pretty strong suspicion that this is happening because Jquery's form submit does not expect or know how to handle a 401 error returning from the server, but I'm not certain where to resolve the issue.
If it matters, I have uncommented the following in the Devise initializer:
config.http_authenticatable_on_xhr = true
I'm also expecting that much of my problem here stems from my lack of understanding about how Rails flash notices are (or are not) integrated in JqueryMobile. Hopefully an answer here will take me that much further towards figuring it out.
jQuery Mobile 'takes over' your form submissions. However, you can simply override this behavior by adding your own form submit listener. If you do that, you should be able to add any custom logic you want.

Rails authorization necessary for post actions?

I have an app I'm writing in rails 3 w/ cancan and devise. I'm curious if authorizing post actions on your controllers is necessary or helpful from a security standpoint? Assuming all my controller actions require authentication w/ devise (ie user must be logged in).
I can see why I need authorization through cancan on my controller actions that use GET's since a user can simply input the url they wish to visit freely and this must be locked down. However, with posts the user must post the data from a form, which is protected against an xss attack with a token.
In this case would it be safe to assume that if i limit the visibility of, say, a button in my view with cancan that the user wouldn't be able to submit a form maliciously?
Thanks alot
EDIT:
Thanks for the quick answer guys. As it has been pointed out below a malicious user can forge a form post using tools such as firebug and thus authorization is necessary.
What would be the best way to simulate this type of interaction (a user posting to an url with a form they've hacked) using capybara / cucumber?
Thanks again.
A user can submit a POST request regardless of whether they are on your website or not. You're correct in thinking that the security token will help prevent XSS, but I would add authentication in for other methods of attacks.
A good (free) ebook to read if you're concerned about security is the Ruby on Rails Security Guide. It outlines all common forms of malicious attacks and even explores some of the lesser used (but just as effective) methods. It also gives great solutions on how to make your application more secure.
You should validate a users authorization in the controller.
With simple tools like FireBug, you can edit the content of a form manually and even add more text fields or similar. The XSS protection won't help you with that.
The user would still be able to generate the button (any method from using Firebug to changing browser code would do) on client side and send the form. If I remember correctly tokens are sent in HTML header co it wouldn't be a problem to forge the form.

Resources