atmos / warden-github Goto Github PK

Now that we're verifying session cookies in #43 see if it's worth doing rails 4 style cookie signing.

https://cowbell-labs.com/2013-04-10-decrypt-rails-4-session.html

@fphilipe running the example app gives me a 404 now. Any ideas?

127.0.0.1 - - [05/Feb/2013 00:51:32] "GET /auth/github/callback?error=redirect_uri_mismatch HTTP/1.1" 404 456 0.0020

I'm using this with your Sinatra gem.

After many debug prints, I found a bug here on this line:
https://github.com/atmos/warden-github/blob/master/lib/warden/github/oauth.rb#L50

That's basically assuming that any time we fail to get exactly what we want in response to authentication, we claim it's a Bad Verification Code, when really, any of the GitHub OAUTH errors will get pushed through there.

My workaround to figure out my problem was to split the line before the rescue into

params = decode_params(response.body)
params.fetch('access_token')

I could then look at the params in the rescue section, which revealed the problem I was having and the easiest way to test this:

I had my GitHub client secret wrong.

Specifically, I was getting the Invalid Client Credentials error from this page:
https://developer.github.com/v3/oauth/#common-errors-for-the-access-token-request

Y'all deprecated gravatar_id in the v3 api but you haven't pushed a new version of this gem after someone updated the warden user to include the avatar_url

Please push a new version

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 imagine, 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.

For enterprise github instances, if octokit is directly configured instead of using environment variables OCTOKIT_ to specify the web domain and the API domain, warden-github may end up using the wrong domain name for authentication. The cause is that Octokit::Configuration::DEFAULT_WEB_DOMAIN is relying on environment only.

I wanted to add a logic to my app that gets triggered by authentication to certain scope.
I added a callback via Warden::Manager.after_set_user, but after_set_user callbacks never get triggered with :authentication event; I'm only seeing :fetch events.

It turned out that the first callback for after_set_user is this one (lib/warden/github/hook.rb) and it throws(:warden) in finalize_flow! which prematurely exits the entire stack of Warden::Proxy#authenticate! ⇒ Warden::Proxy#_perform_authentication ⇒ Warden::Proxy#set_user ⇒ Warden::Manager#_run_callbacks, most importantly skipping the rest of after_set_user callbacks in _run_callbacks.

Not sure if this is a bug or by design, but it would be nice to fix it or document/provide an alternative such that a process can be performed upon authentication (at the beginning of the session).

Right now, I'm using Warden::Manager.prepend_after_authentication to force my callback to come before the one above. It's not a very clean solution but probably an acceptable one if documented.

It looks like the membership data that is supposed to be cached between requests for 5 minutes is not being cached at all.

It looks like it was assumed that the User object would be serialized after each request, storing the modified membership cache in the session. Turns out that the user is only serialized once from Warden::Proxy#set_user that gets called when authentication is successfully performed the first time.

The solution would be to store the membership data (more precisely, any data potentially changing between requests) in Warden::Proxy#session, which "provides a scoped session data for authenticated users". In order to have access to that scoped session data, the User object needs to receive it at time of first initialization and deserialization. It can be retrieved from warden as follows (in both situations env is available): env['warden'].session(scope)

I'll open a PR for this. @atmos since this will need a minor version bump, should I already include it in the PR or would you like to handle that separately?

I created a new Rails app using version 4.1.0.rc2, the latest warden-github release 1.0.1 and Ruby-2.1.1. After performing warden.authenticate! within my controller env['warden'].user results in an string class. Instead of a struct the result looks like a marshaled (Warden::GitHub::User) struct. I tried changing the ruby and warden-github version, but the only way to fix this problem was using the current Rails Version 4.0.4. Don't know if its the new Rails Version / dependencies. Anyone has the same Problem?

Trying bundle install on master (dae6b8e) I get

$ bundle
Fetching gem metadata from https://rubygems.org/.........
Fetching additional metadata from https://rubygems.org/..
Resolving dependencies...
Bundler could not find compatible versions for gem "addressable":
  In Gemfile:
    webmock (~> 1.9) ruby depends on
      addressable (>= 2.2.7) ruby

    addressable (2.2.0)

since (presumably in seconds?) is exposed in the interface but the parameter is not used:
https://github.com/atmos/warden-github/blob/master/lib/warden/github/user.rb#L75-L84