Open dvdplm opened 12 years ago
Please correct me if I'm wrong, but doesn't rack-oauth2 automatically grab the state parameter?
@dvdplm This appears to have some other changes not related to the stated problem it is trying to solve. Specifically it looks like #38 got pulled in. Are there any other PRs or problems that this PR is trying to solve?
@scashin133 you're right, not a very clean PR. Is 770c59ba4ef5e42a8781a87cf548fa803e8da99d still missing upstream? Maybe that and @brmatts changes is all we need? How can I help?
Have you guys reached a conclusion yet? I just got hit by this isssue today. Omniauth-oauth2 strategy added the :state requirement as a default, and will raise a non-descriptive CallbackError if it's missing. devise_oauth2_providable will not work out-of-the-box with Omniauth-oauth2 currently.
"state" param is implemented already as I can see here (actually I was worried too) https://github.com/dvdplm/devise_oauth2_providable/blob/master/app/controllers/devise/oauth2_providable/authorizations_controller.rb#L33
Is there any resolution on this? as noted by @goofrider this is now a requirement in omniauth-oaauth2. It would be greatif the pull could be merged and the results pushed to the gem server! Thanks for providing this. It's a big help!
trying this pull request I'm running into uninitialized constant AuthorizationsController
due to #38 being pulled in I guess, Rails 4
Currently 'rack-oauth2' passes the "state" param when provided but the devise front-end does not. This exposes users to CSRF attacks as outlined here: http://homakov.blogspot.it/2012/07/saferweb-most-common-oauth2.html
The Oauth2 draft strongly advices clients to make use of the "state" param: http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-10.12
This PR sets the
@state
ivar and includes it in the allow/deny form.