doorkeeper-gem / doorkeeper Goto Github PK

I'm talking in sake of supporting other database libraries such as Mongoid

Correct me if i get the code mistaken, but it seems doorkeeper has expires_in for the OAuth token as a required column, which means any token has an explicit expiration time, and that could only be specified as a static value via the configuration file.

I know that doorkeeper supports refresh token mechanism, but it is a bit painful to write the logic to refresh tokens in OAuth2 client applications such as mobile apps, and based on my interviews with some developer friends, their life could be much easier if the site passes a token that never expires (until the user has revoked).

Sites like Foursquare, GitHub and Yammer do this, and Facebook allows this when you request an authorization with offline_access (which they will deprecate but that's another story).

The current workaround may be to set a really long expiration time such as 10 years, but that causes another problem since the expiration time is shared between the token flow and code flow - i want a shorter expiration time for token because of the security.

So - I want some kind of dynamic configuration to override the determination of the expiration time in run time (like Facebook's offline_access), which then supports 0 or some kind of special value to mean "never expires". What do you think?

Per my question in #82 I followed along with the instructions for setting up password flow and hit the following exception:

uninitialized constant Doorkeeper::OAuth::PasswordAccessTokenRequest::ScopeChecker

doorkeeper (0.4.1) lib/doorkeeper/oauth/password_access_token_request.rb:115:in `validate_scope'
doorkeeper (0.4.1) lib/doorkeeper/validations.rb:11:in `block in validate'
doorkeeper (0.4.1) lib/doorkeeper/validations.rb:9:in `each'
doorkeeper (0.4.1) lib/doorkeeper/validations.rb:9:in `validate'
doorkeeper (0.4.1) lib/doorkeeper/oauth/password_access_token_request.rb:29:in `initialize'
doorkeeper (0.4.1) app/controllers/doorkeeper/tokens_controller.rb:29:in `new'
doorkeeper (0.4.1) app/controllers/doorkeeper/tokens_controller.rb:29:in `token'
doorkeeper (0.4.1) app/controllers/doorkeeper/tokens_controller.rb:7:in `create'

I'm on Rails 3.2.5 with Doorkeeper 0.4.1.

Hi,

I'm not sure if this belongs here, but I'm attempting to upgrade from 0.4.2 to the latest version, but I can't seem to find the 0.5.0.dev version with gem 'doorkeeper', '0.4.2' so I am pulling from the github master. However, when I try anything with rails, it gives me the error in the gist here: https://gist.github.com/2933730

Any help would be appreciated as I am trying to override the controller code.

Thanks,
Yihuan

The default layout provided by doorkeeper is nice, but if I want to use my own layout and simply disregard app/views/layouts/doorkeeper/application.html.erb, where would be the best place to start? I'm not all that familiar with engines and simply adding the custom view to my app breaks devise helpers used in my layout.

From OAuth2 v22 spec

The authorization server MUST include the HTTP "Cache-Control" response header field [RFC2616] with a value of "no-store" in any response containing tokens, credentials, or other sensitive information, as well as the "Pragma" response header field [RFC2616] with a value of "no-cache".

For example:

 HTTP/1.1 200 OK
 Content-Type: application/json;charset=UTF-8
 Cache-Control: no-store
 Pragma: no-cache

 {
   "access_token":"2YotnFZFEjr1zCsicMWpAA",
   "token_type":"example",
   "expires_in":3600,
   "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
   "example_parameter":"example_value"
 }

I'm thinking about contributing to the gem by implementing this flow, but first I'd like to know if this is already planned or under execution.

I've seen this fork has a commit about it, that might be a good starting point, although the specs are missing:

epicagency@c095693

I'm trying to figure out how to make doorkeeper work with controllers that use ActionController::Metal as a base class.

I get an error about doorkeeper_for not being defined. I've tried looking through the doorkeeper code to figure out how it's tying into the controller, but so far I can't seem to figure it out.

It appears that this is the code responsible (in the Doorkeeper engine):

    initializer "doorkeeper.helpers" do
      ActiveSupport.on_load(:action_controller) do
        include Doorkeeper::Helpers::Filter
      end
    end

I can't seem to figure out how to make it work with ActionController::Metal rather than ActionController::Base though.

If I change my controller to extend from ActionControlller::Base then everything seems to work fine, unfortunately that isn't really an option for my project.

So the question is: How do I get my controller that uses ActionController::Metal as a base class to be able to use Doorkeeper?

Thanks,
Chris

It would be great to have some sort of 'test user' account for development apps or maybe a read-only setup. Thoughts?

Hi

I have an application that i developed on Rails 2.3.8. In this application i want to use doorkeeper. Is there any version of doorkeeper that I can use? If not, please suggest some alternatives.

Thanks

If the client has been authorized before (has an access token), but then it requests authorization with different scope doorkeeper will not complain. It needs to ask user again whether he accepts the new scope for that client.

Implement HTTP Basic auth for authorization code flow

http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.3

app/views/authorized_applications/index.html.erb is linking each authorized application for the current user to applications#show, where the application uid and secret are being shown.

ApplicationsController can be restricted to admins with :authenticate_admin! , but then it makes no sense linking to applications#show as the user will not be able to see this info.

My proposed solutions are:

a) Don't link, just show the application name

b) Add an "url" column to the Application model, optional, for linking to the external website of the application.

The need for ":authenticate_admin! " should also be enforced on the README.

I can work on this, but I want to know your opinion first.

Is it currently possible to opt out of having the applications & authorized applications routes generated when mounting the engine? I'm interested in providing my own interface for Application management and Authorized Applications isn't necessary in my workflow for the password grant type.

Thanks!

Hi,

I'm working on converting my app from a basis Rails app to using Backbone.js for the frontend. While converting my app, I was looking to make the backend Rails app more behave like an API to which the Backbone.js client talks. I've already converted a large portion of the app to Backbone.js and am now in the process of rewriting the backend to behave like an API.

For authentication I've been using Devise but now I'd like to integrate doorkeeper to use as the authentication system for the Backbone.js < - > Rails interaction.

I already implemented the Provider functionality through your (excellent) examples, but am struggling with the Client part. Basically, I guess my app will function as both the Provider and the Client. Or could the client part be fully done on the Backbone.js side?

Any thoughts on this or ideas how to tackle this? Thanks.

How hard would this be to implement do you think? Maybe a Padrino Provider would be easier, It's built on top of sinatra but lays things out similar to rails and also has quick support for activereocrd etc....

Maybe we could work on one together, as I know a lot of people would find this useful when building a lightweight api.

I think the authentication via header should be like github's curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com rather than what doorkeepers currently is curl -H "Authorization: OAUTH-TOKEN" https://api.github.com. Changing it will allow basic/digest auth etc....

source: http://developer.github.com/v3/

Hello,

I need to use MongoId together with Doorkeeper.
I do as you instruct me to and add this line to the doorkeeper initializer file:

orm :mongoid

I get the error: undefined method `orm'. What is wrong?

Not all of the changes on the v0.3 branch were merged into the master branch. While all of the actual code changes were merged, the following items were not merged:

i) The actual version number change for 0.3.1
ii) The CHANGELOG entry for v0.3.1
iii) Some minor documentation changes

I assume these should be merged over to master.

In AuthorizationRequest we have the following validator:

def validate_redirect_uri
  return false unless redirect_uri
  URIChecker.valid_for_authorization?(redirect_uri, client.redirect_uri)
end

The tests are also explicitly set to enforce the redirect_uri requirement.

However the spec http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4 states that the redirect_uri is an optional parameter in both the Authorization Code (4.1.1) and Implicit Grant (4.2.1) flows and is only required if a client has not previously registered a redirect_uri, or has registered multiple redirect_uris or a partial redirect_uri during an application registration process (3.1.2.3)

[edit - I realized that the client app registration does not require a redirect_uri, so will implement an explicit test]
Since Doorkeeper currently supports only one redirect_uri per client app registration, and since we're doing a direct string comparison also per 3.1.2.3, I think that an explicit check that client.redirect_uri exists before allowing redirect_uri to not be present.

I can implement that and write additional tests if you agree.

This is a proposal rather than a bug report.

How about providing a hook to override the authorization check flow, especially:

  def new
    if authorization.valid?
      if authorization.access_token_exists?  # <- this
        authorization.authorize
        redirect_to authorization.success_redirect_uri
      end

to override authorization.access_token_exists?.

I have two use cases in mind.

One is to force re-confirmation of the authorization screen even when the same set of scopes were granted previously. This is somewhat related to the security consideration section of the spec (10.2):

10.2.  Client Impersonation
...
   The authorization server SHOULD NOT process repeated authorization
   requests automatically (without active resource owner interaction)
   without authenticating the client or relying on other measures to
   ensure the repeated request comes from the original client and not an
   impersonator.

especially with the Implicit Grant flow (response_type=token) it would be better to re-authorize users with a user interaction, since it could be vulnerable to the URL sniffing in an embedded browser situation with a client impersonation.

The other use case is the opposite i.e. skip the confirmation screen even when this is the first time use of the application and there was no previous authorization. This would be useful when handling in-house applications (which btw requires #37 :D) as a kind of "superuser" applications and assume all of these applications are already approved.

Arguably this could be a rare use case, but the spec merely says (4.1.1):

   ... If the request is valid, the
   authorization server authenticates the resource owner and obtains an
   authorization decision (by asking the resource owner or by
   establishing approval via other means).

and this is to support "via other means" :)

To implement this, I guess we can rename the access_token_exists? to something like pre_approved? and let users override it with some configuration block that returns true or false.

Thoughts?

There is an issue with the access_token method in Authorization Request

    def access_token
      AccessToken.accessible.where(:application_id => client.id, :resource_owner_id => resource_owner.id).first
    end

There are two potentially issues here:

i) The query itself doesn't exclude expired tokens. That is, a token where (created_at + expires_in) < Time.now, but that hasn't been explicitly revoked. That token will still be in the database and can (and often will) be returned in this query. While this is checked in the request itself, it is possible that this query will return an expired token even if a valid, unexpired token exists in the table.

ii) This method doesn't have an explicit sort, defaulting to the sort of the underlying data store. As most common databases (MySQL, PostgreSQL, Oracle, etc.) don't guarantee sort results unless an order is specified, this return value is non-deterministic for many data sets.

Handling this in a data-store independent way is a little tricky, as there's no explicit 'expires_at' column in the table on which we can sort. So the easiest way to do it is probably something like this:

    def access_token
      AccessToken.accessible.where(:application_id => client.id, :resource_owner_id => resource_owner.id).where("created_at >= ?", Time.now - expires_in.seconds).order("created_at DESC").first
    end

This could also be moved into the AccessToken class itself, as a factory method.

Thoughts?

Devise has a helper method named devise_for which can be used in the routes DSL to configure which of Devise's controllers get added to the route set. This comes in handy when integrating with a project's existing functionality, or replacing the built-in controllers with your own.

It'd be awesome if Doorkeeper had a similar functionality. For example, on the project I'm working on, we use ActiveAdmin to create new applications, and a custom controller to handle the authorization of new apps to user accounts. Thus, the Doorkeeper-provided app admin, as well as the auth controller, are mapped, but not usable.

Is there any interest in this feature? If so, I'd be glad to implement it.

I've got a Rails 3.0.11 application to which I'd like to add OAuth 2.0 support. Doorkeeper looks like a perfect fit EXCEPT for the fact that it requires Rails 3.1.x.

What are the dependencies on Rails 3.1.x? I see that the migration is a Rails 3.1.x style migration, but is there anything outside the generators that has this dependency? If not, I'd be happy to contribute code enabling Rails 3.0 support.

I see in the wiki https://github.com/applicake/doorkeeper/wiki/Supported-Features it says refresh tokens are on the todo... but In the demo app it's actually creating the fresh token, so has this been implemented? It appears it's only half implemented as when the token expires it doesn't use the fresh one to generate a new token you actually have to sign in again... is that correct?

Many thanks

Tokens I think should be filtered:

• Authorizations tokens
• Access tokens
• Client credentials

Add scopes to access token and add option to doorkeeper_for method that will allow only access tokens with given scope.

Add refresh token flow

I'm testing a clone of the Rails/devise client against a provider I just setup and it seems no matter what I change the redirect_uri to the provider comes back with The redirect uri included is not valid.

I get the same results when following the instructions in Testing your provider...

Log output from the provider: https://gist.github.com/1927858

UPDATE 13/10: Match the RFC http://tools.ietf.org/html/rfc6749

Write documentation about what you need to stub in order to be able to test your controllers that use doorkeeper.

Why doesn't doorkeeper allow a user who is logged in access to a resource?

An example of this is that in our App we are consuming our own API, but want to allow access to the endpoints to users who already have an active session.

doorkeeper_for :all should check if current_user is present and allow access to the resource.

OAuth2 should be an additional authentication strategy and not the only one.

Rails 3.2.2, using config.active_record.whitelist_attributes = true this happens during creation of a new app. It may appear in another places too:

ActiveModel::MassAssignmentSecurity::Error in Doorkeeper::ApplicationsController#create
Can't mass-assign protected attributes: name, redirect_uri

I was wondering why the Doorkeeper gem (version 0.3.2) was a hefty 27MB, and discovered that the logfiles from the dummy app in spec/dummy/log were accidentally included. They're even 322MB uncompressed, so it would be nice if these could be excluded from the Gem :-)

Feature request:

One concept that isn't currently expressed in the gem is client ownership. For example, in the FB API, a client actually belongs to a user account. IOW, I may want the client model to belong to other primitive(s) in the system (e.g., user, company, etc.). This will be useful e.g. for communications to my developers, setting up self-serve app management screens, etc.

I'll take a crack at writing this and commit it back to trunk.

This test case fails:

feature "Authorization Request", "with no scopes" do
  background do
    resource_owner_is_authenticated
    client_exists
  end

  scenario "resource owner gets redirected to authentication" do
    visit authorization_endpoint_url(:client => @client)
    i_should_see "Authorize"
  end
end

Hi,

there may be a problem:

Given Doorkeeper running on https ("force_ssl" enabled)
When a user creates the authorization for an application
Then he will be redirected back to the redirect_uri of the application including the code

This seems to ignore the protocol specified in the redirect_url:

redirect_uri = "http://example.com" => redirect will go to "https://example.com?code=...."

I'm not familiar with the OAuth2 spec but imho this should support plain http, too.

It happens when the provider has no scopes defined.

diff --git spec/dummy/app/controllers/full_protected_resources_controller.rb spec/dummy/app/controllers/full_protected_resources_controller.rb
index b3325fa..91e9099 100644
--- spec/dummy/app/controllers/full_protected_resources_controller.rb
+++ spec/dummy/app/controllers/full_protected_resources_controller.rb
@@ -1,5 +1,6 @@
 class FullProtectedResourcesController < ApplicationController
-  doorkeeper_for :all
+  doorkeeper_for :index
+  doorkeeper_for :show, :scopes => [:admin]

   def index
     render :text => "index"
diff --git spec/requests/protected_resources/private_api_spec.rb spec/requests/protected_resources/private_api_spec.rb
index 2bc2cad..082f9e5 100644
--- spec/requests/protected_resources/private_api_spec.rb
+++ spec/requests/protected_resources/private_api_spec.rb
@@ -25,4 +25,14 @@ feature 'Private API' do
     visit '/full_protected_resources'
     response_status_should_be 401
   end
+
+  scenario 'access token with no scopes fail' do
+    Doorkeeper.configuration.builder.authorization_scopes do
+      scope :admin, :description => "admin"
+    end
+    @token.update_attribute :scopes, nil
+    with_access_token_header @token.token
+    visit '/full_protected_resources/1.json'
+    response_status_should_be 401
+  end
 end

I'm building a Rails API with a separate web frontend app as "just another API client" (various smartphone apps to follow as well). In the previous "monolithic" version of the service, where all the server side was rolled into one Rails app, we used OmniAuth to allow users to sign in with Facebook, Twitter and a few other services.

I see from https://github.com/songkick/oauth2-provider#using-assertions that OAuth "assertions" might be the key in letting us keep this convenient "sign in with [external ID provider]" feature while securing our API with OAuth.

Are assertions supported in Doorkeeper, and if so how do we use them?

I can't thank you guys enough for this gem (literally). I hope I can contribute to this project soon, but until then I have a question: Is it currently possible to specify what information goes into the extras hash? I know facebook delivers some information baout the current resource owner in it, and I think it wouldn't be too shabby eitheir if doorkeeper could offer customization in that regard.

I was peeking in the code, and it looks like one would have to offer an interfact to the AccessToken model?

When I try to delete an application I get this error:

The action 'destroy' could not be found for Doorkeeper::ApplicationsController

Can anyone corroborate this? I'm using 0.3.1

Thanks!

I wonder if it is intentional that the 'spec' directory is excluded from the s.files in the gemspec. Probably these spec files were meant to be used only for testing on your development end, but I've found that some of the helpers and factories in the doorkeeper git repository are useful on my own app testing.

For example, i can use the Factory(:application) to create a new application, then use client_is_authorized to quickly create a new access token, then use with_access_token_header to send a new authorized request.

If they are installed in the gem install, we can load them using our own spec_helper by looking at Gem.loaded_specs and load from spec/support/helpers etc. What do you think?

If the client requests authorization with scope that is not registered in the application it should raise an error

Right now, the gem ships with default views for the OAuth screens. These can be overridden by placing files of the same names in the application path, but that may not be obvious to everyone.

We should probably add a rake task for generating customizable views, similar to what Devise does.

Hi,

I am new to GitHub and OAuth in general, so finding Doorkeeper was a blessing for a good dive. I am currently exploring how to use doorkeeper for a public API, and was wondering how I would go about using doorkeepers scopes to limit access to attributes, not complete actions. Like in the provided examples, we could have like a birthday attribute on the profiles (or users), but only have it visible for a particular application, if:

• the current ressource owner is the requested user
• the other users have provided that scope

Am I on the right track on using the provided scopes, or would I have to come up with my own access control?

This is also less of an issue than a question, but I didnt know where to ask it

I have a use case where allowing doorkeeper_for to be conditional is very helpful.

class ProfilesController < ApiController
   doorkeeper_for :all, :if => { request.xhr? || format.html? }

   def index
      respond_with Profile.all do |format|
        format.html # render documentation
        format.json
      end
   end
end

This is probably an edgecase, but in an app I'm working on, the primary key for the User is a string.

Doorkeeper's oauth_access_tokens and oauth_access_grants' tables don't like that. The validations fail so the resource_owner_id remains at the default of 0. The fix is to dynamically get the type for the resource owner model's primary key.

You can do this like so:

ResourceOwner.columns_hash[ResourceOwner.primary_key].type

The complexity in implementing this is that the user probably needs to specify what the ResourceOwner model is. One way to do that is to ask during the the rails g doorkeeper:install generator.

While I fixed this within the app I'm working on, I'm not sure how you'd want this implemented. I can submit a pull request if you'd like.

So right now my oauth_access_grants table has the same amount of rows as my oauth_access_token table:

Isn't the oauth_access_token table only supposed to have one row per resource_owner_id/application_id ? (I'm using the latest commit 4b0e566)

p.s. thank you for this lib :D

OAuth 2 Spec define two client types, which are public and confidential

This types affects some flows, like Client Credentials Grant, which requires clients to be confidential for example.

This is the spec which refers to it: http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-2.1

I have a very strange error pop up from time to time. I'll get this when I try to go to /oauth/applications:

NoMethodError (undefined method `authenticate_admin!' for #<Doorkeeper::ApplicationsController:0x007f8f359b3b80>):

And when I restart webrick it will go away. In the same vain it will sometimes redirect me for no apparent reason to the login page (as per the config). The token has not been revoked or expired.

Started GET "/api/v1/purchases.json" for 127.0.0.1 at 2012-02-07 10:50:00 +0000
  Processing by PurchasesController#index as JSON
Redirected to http://localhost:3000/login
Completed 302 Found in 11ms

My configuration is as follow:

Doorkeeper.configure do
  resource_owner_authenticator do |routes|
    current_user || redirect_to(routes.sign_in_path, :alert => t('needs_to_sign_in'))
  end

  admin_authenticator do |routes|
    current_admin || redirect_to(routes.root_path)
  end

  access_token_expires_in 12.hours
  use_refresh_token
end

I don't even know where to begin to try and debug this. Any ideas?