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.
Bates’ RailsCast is for Rails 3 (3.2, to be exact.) Here are some things that have changed in Rails4:
- 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.
- 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.
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 userrather 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 parameterI am not sure why I wrote this because I don’t see the callback parameter name being used in the video – my bad?
callbackfor 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
Enjoy your Rails journey!