Sameer Siruguri

My Blog

Rails(cast) Gotcha: Using Devise, Doorkeeper and OAuth2 defaults

Now with Rails4 updates! This post has been getting a lot of search engine love, so I’m working on making it as helpful as possible. Feel free to ask questions in the comments section!

I love Ryan Bates, and I love Railscasts! The Rails learning curve is significantly leveled down by these excellent tutorials, or at least it adds a very helpful set of railings to drag oneself up that hill by.

I’m trying to hook up Devise and Doorkeeper together to build an application that is going to expose its data via an API. If you, like me, are learning how to do this using Mr Bates’ excellent teachings, you will probably have listened to Railscast #209, and are in the middle of Railscast #353.

I thought I’d add some notes for future n00bs to consider, based on a few hiccups I had:

To begin with, if you are wondering what OAuth is (or even if you just want to brush up on the basics,) I’ve written an OAuth primer that might be helpful. It will certainly help understand the terminology used in this post.

Rails4 Updates

Bates’ RailsCast is for Rails 3 (3.2, to be exact.) Here are some things that have changed in Rails4:

  1. Installation: The doorkeeper:install task doesn’t generate migrations any more. You have to run a separate task – if you’re using ActiveRecord as your ORM, you have to run rails generate doorkeeper:migration.
  2. Defaults: The latest Doorkeeper gem (v1.0.0, as of this update) code includes an exception in the config/initializers/doorkeeper.rb to remind you to set the authenticator block that you have to remove.

I don’t remember if this was true of Devise when I last looked at it, but it seems that it offers both an interesting variation of 2-legged OAuth, which I think is really the best way to do OAuth – if you call the authorize route (the default is /oauth/authorize) with the query string response_type=token, you can get an access token right away without having to first get the request token. Bates’ examples don’t mention this.


http://localhost:3000/oauth/authorize?response_type=token&client_id=my_application_id&client_secret=my_client_secret&redirect_uri=http://localhost:3001/client_callback

Okay – now here’s everything else that was the same the last time around:

  • When you use Devise as your authentication solution, you want to find the current user that is authenticated via current user rather than the User.find_by_ code that’s in the Doorkeeper initializer by default. You’ll find yourself being redirected to the Devise root instead of going to the Doorkeeper views if you don’t do this because there’s no user_id key in your session by default. This is also mentioned in the Doorkeeper documentation in the Authenticating section.
  • The OAuth2 gem uses certain defaults to generate the authorization URI – one of them is to assume that your OAuth provide route is /oauth/authorize (which it will be if you use the Doorkeeper defaults), and the other is to use the parameter callback for the callback URI. The latter won’t work though because the Doorkeeper gem default is to expect the callback URI to be specified with the redirect_uri parameter instead. So change callback= to redirect_uri= I am not sure why I wrote this because I don’t see the callback parameter name being used in the video – my bad? 

Enjoy your Rails journey!

Single Post Navigation

3 thoughts on “Rails(cast) Gotcha: Using Devise, Doorkeeper and OAuth2 defaults

  1. Hello!

    I’m facing the same problem you described with the callbacks path. Could you please give the total noob version of how to fix it?

    Thank you!

  2. Sameer Siruguri on said:

    @Pedro – I just got around to looking at this post and updated it based on a re-watch of the Railscast, and on the latest Doorkeeper behavior. I couldn’t see though where there was a problem with the callbacks path – but I’d be happy to try and fix your problem – can you say more about what exactly you faced/are facing?

  3. Hi Sameer, thanks for this post, this help me a lot to find out why i wasn’t able to get this working… is also was following the Rails cast video…

    Another thing that was mentioned on the video and in the last version of doorkeeper isn’t support anymore is the method doorkeeper_for

    in video Ryan mention the use of doorkeeper_for :all in the controller, to ensure that all actions need to be authorised by doorkeeper and now the method we should use is doorkeeper_authorize! in a before_filter or before_action (depending on rails version)

    Regards!

Leave a Reply

Your email address will not be published. Required fields are marked *