sharpstone / heroku-bouncer Goto Github PK

View Code? Open in Web Editor NEW

41.0 41.0 15.0 35.81 MB

A Heroku OAuth middleware with no other work to do

License: MIT License

Ruby 98.67% HTML 1.33%

heroku-bouncer's People

Contributors

Stargazers

Watchers

Forkers

epictetus gregburek adamcarlile jackca recurser cbartlett maxbeizer wuputah ericc572 mmrobins stevenharman wilsonsilva isabella232

heroku-bouncer's Issues

Testing without environment

In a bunch of cases when testing apps using bouncer the environment isn't available (for instance, plain old travis, bundle exec rspec, Travis etc.

Bouncer falls over as it requires an id an secret.

Can we resolve this by setting a default id and secret in builder.rb if RACK_ENV or RAILS_ENV are present and set to test?

Bouncer should fail hard if the required configuration is not present

https://github.com/heroku/heroku-bouncer/blob/7760adc7b295036d511ad0c92975fea9d35087de/lib/heroku/bouncer/builder.rb#L37

Replace heroku-api gem with platform-api

Bundling a fresh app with this gem returns:

‼️       The heroku-api gem will not work.
‼️       You must instead use the platform-api gem.
‼️       The heroku-api gem communicated with the Legacy API which has been disabled.
‼️       https://devcenter.heroku.com/changelog-items/118

Handling Heroku::API::Errors::Unauthorized

In the case that a user's token has expired - perhaps because they've logged out and back in on another machine, API requests will raise Heroku::API::Errors::Unauthorized

In log2viz, I've added the following error handler to catch this:

  error Heroku::API::Errors::Unauthorized do 
    session[:return_to] = request.url
    redirect to('/auth/heroku')
  end

Any thoughts on making this a default behavior? Or at least offering a helper to reauth the user without redirecting to /auth/logout?

Middleware issues in Rails 4

Test app: https://github.com/neilmiddleton/broken-middleware

Note raise in https://github.com/neilmiddleton/broken-middleware/blob/master/lib/health_report_bouncer.rb#L8

On 0.3.4 I see the raise as expected. On 0.4.0.pre3 the raise doesn't fire (it implies that the subclassed #call is being replaced somehow.)

NameError (undefined local variable or method `local_variables' for #<Heroku::Bouncer::Lockbox:0x007f83075d9af8>):

NameError (undefined local variable or method `local_variables' for #<Heroku::Bouncer::Lockbox:0x007f83075d9af8>):
  heroku-bouncer (0.8.0) lib/heroku/bouncer/lockbox.rb:11:in `lock'
  better_errors (2.1.1) lib/better_errors/stack_frame.rb:71:in `eval'
  better_errors (2.1.1) lib/better_errors/stack_frame.rb:71:in `local_variables'

No instructions for use with Rails

I get errors when using this on a Rails 3 and a Rails 4 app. The authentication succeeds - but hitting the app after authentication causes many errors like this one:

10:48:59 web.1    | started with pid 3706
10:49:17 web.1    | ThreadError - deadlock; recursive locking:
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.4.5/lib/rack/lock.rb:14:in `lock'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.4.5/lib/rack/lock.rb:14:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/actionpack-3.2.13/lib/action_dispatch/middleware/static.rb:63:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/engine.rb:479:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/application.rb:223:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/railtie/configurable.rb:30:in `method_missing'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:929:in `forward'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1000:in `route_missing'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:961:in `route!'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:957:in `route!'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1059:in `block in dispatch!'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `block in invoke'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `catch'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `invoke'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1056:in `dispatch!'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:882:in `block in call!'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `block in invoke'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `catch'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `invoke'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:882:in `call!'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:870:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/heroku-bouncer-0.3.0/lib/heroku/bouncer.rb:48:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/omniauth-1.1.4/lib/omniauth/strategy.rb:184:in `call!'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/omniauth-1.1.4/lib/omniauth/strategy.rb:164:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/omniauth-1.1.4/lib/omniauth/builder.rb:49:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/encrypted_cookie-0.0.4/lib/encrypted_cookie.rb:39:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-protection-1.5.0/lib/rack/protection/xss_header.rb:18:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-protection-1.5.0/lib/rack/protection/path_traversal.rb:16:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-protection-1.5.0/lib/rack/protection/json_csrf.rb:18:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-protection-1.5.0/lib/rack/protection/base.rb:49:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-protection-1.5.0/lib/rack/protection/base.rb:49:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-protection-1.5.0/lib/rack/protection/frame_options.rb:31:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.4.5/lib/rack/nulllogger.rb:9:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.4.5/lib/rack/head.rb:9:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:175:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/sinatra-1.4.3/lib/sinatra/base.rb:1949:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.4.5/lib/rack/content_length.rb:14:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/rack/log_tailer.rb:17:in `call'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/connection.rb:81:in `block in pre_process'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/connection.rb:79:in `catch'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/connection.rb:79:in `pre_process'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/connection.rb:54:in `process'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/connection.rb:39:in `receive_data'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run_machine'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/eventmachine-1.0.3/lib/eventmachine.rb:187:in `run'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/backends/base.rb:63:in `start'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/thin-1.5.1/lib/thin/server.rb:159:in `start'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.4.5/lib/rack/handler/thin.rb:13:in `run'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/rack-1.4.5/lib/rack/server.rb:268:in `start'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/commands/server.rb:70:in `start'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/commands.rb:55:in `block in <top (required)>'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/commands.rb:50:in `tap'
10:49:17 web.1    | /Users/jonmountjoy/.rvm/gems/ruby-2.0.0-p247/gems/railties-3.2.13/lib/rails/commands.rb:50:in `<top (required)>'
10:49:17 web.1    | script/rails:6:in `require'
10:49:17 web.1    | script/rails:6:in `<main>'

Currently, bouncer does not have anyway to stub successful sessions to avoid the oauth redirect/callback flow, when running integration/feature tests. A potential way to avoid this is to avoid running bouncer, and stub the request.env object in your tests:

allow_any_instance_of(ActionDispatch::Request).to receive(:env).and_wrap_original do |m, *args|
  m.call(*args).merge!('bouncer.user' => {'email' => '[email protected]'})
end

It would be much better if we could put bouncer into a 'test' mode, that allowed us to natively stub the middleware and request.env.

A proposed API:

# in global test setup
::Heroku::Bouncer.enable_test_mode(user: {'email' => '[email protected]'})

# in global test teardown
::Heroku::Bouncer.disable_test_mode

# In test, restricting bouncer test to block
::Heroku::Bouncer.test_mode(user: {'email' => '[email protected]'}) do
  visit '/'
  expect(page.status_code).to be(200)
end

undefined method `lock` for nil:NilClass

This occurs on the following line when making a session-less POST (i.e. curl) when allow_anonymous evaluates to true:

https://github.com/heroku/heroku-bouncer/blob/master/lib/heroku/bouncer/middleware.rb#L172

OpenSSL::Cipher::Cipher is deprecated in Ruby 2.4.0

Since upgrading to Ruby 2.4.0, I've been getting this warning:

[...]/ruby/gems/2.4.0/gems/heroku-bouncer-0.7.1/lib/heroku/bouncer/lockbox.rb:24: warning: constant OpenSSL::Cipher::Cipher is deprecated

Use API v3 /account endpoint

With the shiny new allow_if_user hook #42 added I'd like to check for two_factor_authentication but it's not returned on the v2 /account endpoint.

cc @jacobian

make testing easier

It'd be nice if testing in apps with OmniAuth.config.test_mode = true didn't involve having to stub Heroku::Bouncer::Middleware#fetch_user.

Repeated requests reuse modified `options` hash

I was investigating this spamming my logs:

2014-05-27T04:48:16.558409+00:00 app[web.2]: [warn] heroku-bouncer: HEROKU_ID or HEROKU_OAUTH_ID detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:16.558645+00:00 app[web.2]: [warn] heroku-bouncer: HEROKU_SECRET or HEROKU_OAUTH_SECRET detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:18.573900+00:00 app[web.1]: [warn] heroku-bouncer: HEROKU_SECRET or HEROKU_OAUTH_SECRET detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:18.573890+00:00 app[web.1]: [warn] heroku-bouncer: HEROKU_ID or HEROKU_OAUTH_ID detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:20.559529+00:00 app[web.2]: [warn] heroku-bouncer: HEROKU_ID or HEROKU_OAUTH_ID detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:20.559539+00:00 app[web.2]: [warn] heroku-bouncer: HEROKU_SECRET or HEROKU_OAUTH_SECRET detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:22.558107+00:00 app[web.2]: [warn] heroku-bouncer: HEROKU_SECRET or HEROKU_OAUTH_SECRET detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:22.558094+00:00 app[web.2]: [warn] heroku-bouncer: HEROKU_ID or HEROKU_OAUTH_ID detected in environment, please pass in :oauth hash instead
2014-05-27T04:48:24.562284+00:00 app[web.2]: [warn] heroku-bouncer: HEROKU_ID or HEROKU_OAUTH_ID detected in environment, please pass in :oauth hash instead

I found that if slightly different variable names are used, repeated requests seem to skip the options and pass in nil for the oauth hash.

.env file:

HEROKU_OAUTH_IDX=0000-0000
HEROKU_OAUTH_SECRETX=0000-0000
HEROKU_BOUNCER_SECRETX=0000-0000
SESSION_SECRET=lol

./config.ru

run Routes

./lib/routes.rb

Routes = Rack::Builder.new do
  use Rack::Session::Cookie, key: 'rack.session', 
    secret: ENV['SESSION_SECRET']

  use Heroku::Bouncer,
    oauth: { id: ENV['HEROKU_OAUTH_IDX'], secret: ENV['HEROKU_OAUTH_SECRETX'] },
    secret: ENV['HEROKU_BOUNCER_SECRETX'],                                      
    herokai_only: true
end

First request goes through, but subsequent requests throw errors:

> bundle exec foreman start web
22:23:30 web.1       | started with pid 32420
22:23:31 web.1       | [32420] Puma starting in cluster mode...
22:23:31 web.1       | [32420] * Version 2.8.2 (ruby 2.1.1-p76), codename: Sir Edmund Percival Hillary
22:23:31 web.1       | [32420] * Min threads: 1, max threads: 16
22:23:31 web.1       | [32420] * Environment: development
22:23:31 web.1       | [32420] * Process workers: 3
22:23:31 web.1       | [32420] * Preloading application

22:23:31 web.1       | [32420] * Listening on tcp://0.0.0.0:5000
22:23:31 web.1       | [32420] Use Ctrl-C to stop
22:23:31 web.1       | [32420] - Worker 0 (pid: 32422) booted, phase: 0
22:23:31 web.1       | [32420] - Worker 1 (pid: 32423) booted, phase: 0
22:23:31 web.1       | [32420] - Worker 2 (pid: 32424) booted, phase: 0
22:23:34 web.1       | request_id=7464b7dd-1966-488e-9856-d08fa56482d1 instrumentation at=start method=GET path=/
22:23:34 web.1       | request_id=7464b7dd-1966-488e-9856-d08fa56482d1 instrumentation at=finish method=GET path=/ route_signature=/ status=200 elapsed=0.013
22:23:35 web.1       | [fatal] heroku-bouncer: HEROKU_OAUTH_ID or HEROKU_OAUTH_SECRET not set, middleware disabled
22:23:35 web.1       | E, [2014-05-27T05:23:35.519786 #32423] ERROR -- : Reporting exception: undefined method `empty?' for nil:NilClass
22:23:35 web.1       | I, [2014-05-27T05:23:35.521960 #32423]  INFO -- : [Rollbar] Scheduling payload
22:23:35 web.1       | I, [2014-05-27T05:23:35.522174 #32423]  INFO -- : [Rollbar] Sending payload
22:23:36 web.1       | I, [2014-05-27T05:23:36.117344 #32423]  INFO -- : [Rollbar] Success
22:23:36 web.1       | I, [2014-05-27T05:23:36.117493 #32423]  INFO -- : [Rollbar] Details: https://rollbar.com/instance/uuid?uuid=fbcac033-f95d-4c94-8f0a-e346df41c894 (only available if report was successful)
22:23:36 web.1       | D, [2014-05-27T05:23:36.117566 #32423] DEBUG -- : [Rollbar] Exception uuid saved in env: fbcac033-f95d-4c94-8f0a-e346df41c894
22:23:36 web.1       | 2014-05-27 05:23:36 +0000: Rack app error: #<NoMethodError: undefined method `empty?' for nil:NilClass>
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/heroku-bouncer-0.4.2/lib/heroku/bouncer/builder.rb:10:in `new'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/heroku-bouncer-0.4.2/lib/heroku/bouncer.rb:5:in `new'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:86:in `block in use'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:134:in `[]'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:134:in `block in to_app'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:134:in `each'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:134:in `inject'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:134:in `to_app'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rack-1.5.2/lib/rack/builder.rb:138:in `call'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/rollbar-0.12.18/lib/rollbar/middleware/rack/builder.rb:8:in `call_with_rollbar'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/puma-2.8.2/lib/puma/configuration.rb:71:in `call'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/puma-2.8.2/lib/puma/server.rb:490:in `handle_request'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/puma-2.8.2/lib/puma/server.rb:361:in `process_client'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/puma-2.8.2/lib/puma/server.rb:254:in `block in run'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/puma-2.8.2/lib/puma/thread_pool.rb:92:in `call'
22:23:36 web.1       | /usr/local/var/rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/puma-2.8.2/lib/puma/thread_pool.rb:92:in `block in spawn_thread'

Any ideas? Is the session not reusing the existing rack stack here?

License missing from gemspec

RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.

via e.g.

spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']

Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can image, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.

There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.

I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!

Appendix:

If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies

p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.

Redirect loop

We're using a vendored version corresponding to the PR I submitted last week. After replacing it with the repo's version I've noticed that it runs into a redirect loop. I'll investigate further, but want to leave a warning here anyway.

Rename `HEROKU_` defaults?

As reported by @maxbeizer, Bouncer encourages the usage of env vars with a HEROKU_ prefix - should we rename these defaults? (In which case we should also modify https://github.com/heroku/omniauth-heroku).

devise token auth conflict breaks /auth/heroku route

Am I missing something? I would expect to be redirected to a heroku server, and THEN be redirected back to my own service after a valid auth.

No where does this middleware implement /auth/heroku (different than /auth/heroku/callback).

Is this something that needs to be implemented in my own service? If so I do not see documentation to this effect.

here's my middleware config

config.middleware.use ::Heroku::Bouncer,
        oauth: {
          id: ENV['ADMIN_OAUTH_ID'],
          secret: ENV['ADMIN_OAUTH_SECRET']
        },
        secret: ENV['ADMIN_COOKIE_SECRET'],
        expose_token: true

Heads up w/ Rails 5

Bundler could not find compatible versions for gem "rack":
  In Gemfile:
    rails (~> 5.0.0) was resolved to 5.0.0, which depends on
      railties (= 5.0.0) was resolved to 5.0.0, which depends on
        actionpack (= 5.0.0) was resolved to 5.0.0, which depends on
          rack (~> 2.0)

    heroku-bouncer (~> 0.6.0) was resolved to 0.6.0, which depends on
      rack (~> 1.0)

Update omniauth

Omniauth has several security issues. The 0.8 constraints rely on unpatched versions.
https://nvd.nist.gov/vuln/detail/CVE-2017-18076

Unable to log out

You're using session = nil to log a user out, but this only sets the session variable in the scope of that method to nil. This should probably be session.clear instead, but this causes an exception right now at https://github.com/heroku/heroku-bouncer/blob/master/lib/heroku/bouncer/middleware.rb#L115.

Support OAuth scopes

@will: it'd be super cool to support the different oauth scopes

key must be 32 bytes

Currently upgrading to Ruby 2.4.2 is breaking bouncer.

"[warn] heroku-bouncer: `herokai_only` option is deprecated: please use `allow_if` instead" in logs constantly

v0.5.0 introduced this commit, which causes warnings in logs even if you're not using the herokai_only flag:

[warn] heroku-bouncer: `herokai_only` option is deprecated: please use `allow_if` instead
even though we are not using the herokai_only option :panda_face:

The method extract_deprecated_option is called for (I assume) every request here, prompting the warning to be issued.

Disparity between bouncer and heroku-oauth

In the heroku/heroku-oauth readme:

$ heroku clients:create -s Amazing https://amazing-client.herokuapp.com/auth/heroku/callback >> .env

This doesn't work for bouncer as the key names are different.

Can we get bouncer to understand/use HEROKU_SECRET and HEROKU_KEY?