Release Candidate v2.0.0-rc1 Feedback & Discussion

[BobbyMcWho]

I have released v2.0.0-rc1 and I am looking for feedback, as well as help from folks in testing it across various adapters.

Please read through the release notes, as it explains a lot.

My main goal with this release is to remove the vulnerable-by-default configuration of omniauth that causes CVE-2015-9284 to still to this day be unresolved.

I also included various other behavior fixes and changes that were requested, but left un-reviewed or un-merged for, in some cases, years.

I have done my best to limit the effect on most applications, but by no-means should you treat this as plug and play to prod. I'd appreciate any strategy maintainers inputs and testing with their strategies.

I've tested this release candidate in discourse (PR) and the tests are passing with minor application logic changes. The build failures are due to plugin dependencies requiring a pessimistic 1.x of omniauth (as they should), but you can see the previous build (using a branch rather than the release candidate) passed all tests.

[urkle]

@BobbyMcWho What I don't see in the changelog is a means to handle the scenario where I want to wrap the auth handling with my own controller ( see comment #809 (comment) ). If there were a means provided in OmniAuth for me to directly call the "logic" of those routes without having to actually redirect to them then I would easily be able to ensure security in my app without having to rely on the old "GET" routes.

[BobbyMcWho]

@urkle OmniAuth is a rack middleware, and by the time you've hit a rails controller, you've already run through your middleware stack. Now there may be some way for you to manually send the rails request.env through an omniauth strategy in the controller, but it's definitely not the intended use case of this gem.

Perhaps rolling something yourself utilizing the oauth2 gem would make the most sense for your application?

[jkowens]

@BobbyMcWho I was just reading over the wiki docs for upgrading to 2.0 and I was wondering if this open PR for rack-protection would simplify the upgrade for Rails projects: sinatra/sinatra#1653?

I think that should allow Rails compatibility by doing this:

OmniAuth.config.request_validation_phase = OmniAuth::AuthenticityTokenProtection.new(key: :_csrf_token)

Of course that depends on that PR getting merged and released, but I'm optimistic it will.

[BobbyMcWho]

I think that could be a reasonable path to take, since providing the key will be backwards compatible. I’m more than happy to review a PR should one come in once the rack changes are merged

[suprnova32]

@BobbyMcWho I think it's safe to release v2.0 already. There are 83 installs from Rubygems for this RC, and no feedback has been submitted, positive or negative. We should just go ahead.

[BobbyMcWho]

Yup, I will release it in the next few days I believe

[jscharf]

Small bit of feedback: when I update my Gemfile to the following:

gem 'omniauth', '2.0.0-rc1'`

I see the following runtime error after running bundle and rails s:

You are using an old OmniAuth version, please ensure you have 1.0.0.pr2 version or later installed. (RuntimeError)

This is coming from Devise (I'm on version 4.7.1) omniauth.rb
https://github.com/heartcombo/devise/blob/master/lib/devise/omniauth.rb#L12

Just wanted to mention it in case it hadn't been discussed already.

[jkowens]

Looks like they're in the process of fixing that: heartcombo/devise#5327

[sicktastic]

I am getting the same error when I try to deploy to production. It looks like the pull request is still WIP.

[BobbyMcWho]

Yes if you're using Devise, they are working on supporting 2.0.0

[BobbyMcWho]

This has been released as OmniAuth v2.0.0