-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve OmniAuth version check to allow anything from 1.0 forward #5327
Conversation
This should enable people to try OmniAuth 2 currently in pre-release.
Any chance that this will get merged? OmniAuth 2 has been released. |
Please check the issue for more info. OmniAuth 2 was released yesterday, but the work here hasn't been finished. Thanks. |
@dcangulo It's also likely that some of your OmniAuth strategies will need updates, so I'd take a look at the strategies you use and make PRs where necessary to help the maintainers out. |
Not sure if this is the right place here but after upgrading to 8bb358c I am running into the "Not found. Authentication passthru." error when trying to authenticate with Facebook (using omniauth-facebook) which didn’t happen before the upgrade. |
Thanks for testing and passing along the feedback @ohlhaver. I did notice a few tests failed on OmniAuth2 once I got it running locally, I'm gonna see if there's any change required in Devise to support it. |
@ohlhaver is that authentication to Facebook via a GET request? I believe that's part of the resolution for the CVE that motivated the 2.0 release. |
Not absolutely sure. It's the call to user_facebook_omniauth_authorize_path without any further parameters, so I guess it's a GET request? |
But probably we're still blocked on heartcombo/devise#5327
omniauth-openid v2.0.1 was just released opening support for omniauth v2, so we can bundle update everything from the released gems now.
@ohlhaver if you're testing out this branch please make sure to get the latest, and let me know if you run into any trouble. If you've customized the Devise shared links template, or have your own links/buttons to initiate the "Facebook OmniAuth" authorization, those need to be changed to do a POST request like mentioned above. See the diff for an example. For links you can change them to use |
For anyone now getting the error I resolved it with:
|
Indeed, it does help as a temporary solution |
@thebravoman @yshmarov this is essentially preventing/ignoring the OmniAuth upgrade, if that's what you want to achieve for now? If you'd like, you should be able to try out OmniAuth 2 by pointing Devise to this branch. If you happen to give it a shot, please report back with any feedback. Thanks. |
First I tried this |
I'd recommend using the branch ref instead of the git ref directly: gem 'devise', github: 'heartcombo/devise', branch: 'ca-omniauth-2' With that you should be able to run Lastly, if you've copied over the Devise shared links on your app, or if you have your own links to initiate the OmniAuth authentication flow, you need to make sure they're changed to use a form. (you can do that by using link_to with |
Oh yes @yshmarov @carlosantoniodasilva I also see this a temporary solution that is perfectly fine for me. I will happily wait for the next release of devise that is using omniauth-2. |
lib/devise/omniauth.rb
Outdated
unless OmniAuth::VERSION =~ /^1\./ | ||
raise "You are using an old OmniAuth version, please ensure you have 1.0.0.pr2 version or later installed." | ||
if Gem::Version.new(OmniAuth::VERSION) < Gem::Version.new('1.0.0') | ||
raise "You are using an old OmniAuth version, please ensure you have 1.0.0 version or later installed." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we use gem 'omniauth', '>= 1.0.0.pr2'
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you mean use the gem
command instead of the manual version check here? That's probably best yes, I'll update.
Or is it about the pr2
version? I thought we could just set to 1.0+ stable and don't allow the pr/rc ones anymore.
There was very little change between the two omniauth/omniauth@v1.0.0.pr2...v1.0.0, and hopefully there's no one else running those pre-stable versions.
And a note/warning about how it might break apps that don't update their integration accordingly as OmniAuth now expects.
Still works in 2021 yo! |
@CornerstoneII well, this is all 2021 ;) It'd be great if you could try out this branch though, to help make sure it works. I'm gonna work on a new release containing these changes this week. |
This reverts commit 628f2fb. We should be run green on OmniAuth 2.x now.
I'm sure more people will hit issues so I'm trying to add more guidance here about how to upgrade... maybe that should be in its own wiki but I'll keep it all in the changelog for now.
Is it okay to still use this?
Or leaving out the branch name is fine? |
@leni1 since this has been merged you can point to the master branch instead (omitting it should work too for now, I think.) I kept the branch around to avoid breaking anyone already relying on it, but it will be deleted at some point so better to rely on master. |
I see that this is merged. When do you expect it will be released? |
@thebravoman no specific ETA yet, please see here for more info: #5326 (comment) |
@carlosantoniodasilva thanks. Looking forward to. |
@carlosantoniodasilva No rush, but still no ETA? |
Email from GitHub ``` [GitHub API] Deprecation notice for authentication via URL query parameters GitHub Mar 6, 2021, 4:37 AM (5 days ago) to Richard Hi @schneems, On March 6th, 2021 at 10:37 (UTC) your application (CodeTriage) used an access token (with the User-Agent Faraday v0.17.3) as part of a query parameter to access an endpoint through the GitHub API: https://api.github.com/user Please use the Authorization HTTP header instead as using the `access_token` query parameter is deprecated. Depending on your API usage, we'll be sending you this email reminder on a monthly basis. Visit https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param for more information about suggested workarounds and removal dates. Thanks, The GitHub Team ``` Need to use devise from GitHub due to this not being released yet heartcombo/devise#5327
Hello! How soon it is possible to bump a new patch version with this fix? Perhaps, it is possible to release only this fix alone in a patch version? According to my test the branch Can I do something to help you beyond the testing? |
@Mikopet you can use devise master branch directly instead of this one. (I didn't delete it because I was pretty sure some people were relying on it directly, but it will eventually be removed) The fix is bigger than a patch version would deserve I think. but I'm not ready to bump major, and I wanted to include a few other things before releasing a new version (minor in this case), but I haven't been able to wrap them up. I'll see about doing that release anyway with what's in master. |
Email from GitHub ``` [GitHub API] Deprecation notice for authentication via URL query parameters GitHub Mar 6, 2021, 4:37 AM (5 days ago) to Richard Hi @schneems, On March 6th, 2021 at 10:37 (UTC) your application (CodeTriage) used an access token (with the User-Agent Faraday v0.17.3) as part of a query parameter to access an endpoint through the GitHub API: https://api.github.com/user Please use the Authorization HTTP header instead as using the `access_token` query parameter is deprecated. Depending on your API usage, we'll be sending you this email reminder on a monthly basis. Visit https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param for more information about suggested workarounds and removal dates. Thanks, The GitHub Team ``` Need to use devise from GitHub due to this not being released yet heartcombo/devise#5327
Updates omniauth because GitHub is deprecating query params which is used by the old omniauth. To do this I updated to Omniauth 2+ which also required an update of devise. There's a change to the omniauth API which is talked about here: heartcombo/devise#5236 Basically: - Omniauth2 requires post (instead of GET) - Omniauth 2 also needs this `omniauth-rails_csrf_protection` gem. I added the gem and updated all `link_to` and `button_to` to include a `method: :post`. There is one controller redirect which apparently still seems to work, but it might be broken. I'm not sure how we could possibly preserve the existing behavior since you cannot redirect to a post. This gets tests to pass though. So it's good enough for the short term. ## Deprecation Email from GitHub ``` [GitHub API] Deprecation notice for authentication via URL query parameters GitHub Mar 6, 2021, 4:37 AM (5 days ago) to Richard Hi @schneems, On March 6th, 2021 at 10:37 (UTC) your application (CodeTriage) used an access token (with the User-Agent Faraday v0.17.3) as part of a query parameter to access an endpoint through the GitHub API: https://api.github.com/user Please use the Authorization HTTP header instead as using the `access_token` query parameter is deprecated. Depending on your API usage, we'll be sending you this email reminder on a monthly basis. Visit https://developer.github.com/changes/2020-02-10-deprecating-auth-through-query-param for more information about suggested workarounds and removal dates. Thanks, The GitHub Team ``` Need to use devise from GitHub due to this not being released yet heartcombo/devise#5327 # This is the commit message #2: WIP Move omniauth links to post Omniauth 2 requires post. heartcombo/devise#5236 ``` Install the gem OmniAuth - Rails CSRF Protection Add the link user_facebook_omniauth_authorize_path method: :post ``` TODO: Convert the rest of the links to `user_github_omniauth_authorize_path` to be post
Hey! Any news with new release? |
I just pushed v4.8 including this change, please give it a try and report back if you have any issues. Thanks. |
In our applications, we have been using a custom However, it looks like the change in behavior in OmniAuth rendered our handling of this use case inoperable. Given that a Just thought I would add a comment here to help others who are in the same boat or in case some part of my analysis of the failures we're seeing after attempting to update to OmniAuth 2.0 is incorrect. |
@md5 thanks for the mention here, that makes sense. Apologies for the extra work this is going to add to your team. Please note that it is still possible to use GET, keeping the existing behavior, but it's really advisable not to, as that was the reason for the security issue in the first place. (see their release notes: https://github.com/omniauth/omniauth/releases/tag/v2.0.0 and the associated CVE info: https://github.com/omniauth/omniauth/wiki/Resolving-CVE-2015-9284). There's also more information about how an attacker could use this to take control over someone else's account in this issue: omniauth/omniauth#809. In the v2 release notes there's a section on how to use GET and how to prevent the warning OmniAuth will start raising then. You can do that, but like mentioned above, not super recommended, and if you do so it might be good to research alternatives to prevent the attack in question. (I don't know of anything of the top of my head). |
this is required to sidestep the fact that Devise has compatible Omniauth versions hardcoded as '1.x.x' and Omniauth has recently gone '2.0.x'. the Devise maintainer is planning a release that will include the fix for this, in the meantime advised for people to keep using this branch. See heartcombo/devise#5327 for more details.
This should enable people to try OmniAuth 2 currently in pre-release.
Closes #5326, And I believe also closes #5236. (for now at least)
TO-DO