I’m sitting at a table at Windy City Rails, a Ruby on Rails conference in Chicago. We’ve seen some excellent talks over the morning, but one that particularly spoke to me so far is the talk “What Devise Does When You’re Not Looking” by Lucas Mazza from Platformatec.

The thing is, lots of us use the Devise user authentication gem without worrying too much about what it does for us. It’s time to demystify its inner workings, and that’s what Lucas set out to do in his talk.

What does Devise do…and what doesn’t it do?

• Devise relies on a gem called Warden for its authentication system. This documentation for Warden provides the “what” and the “why,” and it’s relatively easy to read.
• FailureApp, defined by Warden, is the way devise throws away a request from an unauthenticated user who should be authenticated.
• So what does Devise do? Well, in many cases it extends how Warden works to make the authentication system easily customizable for the user. For example, Devise provides a custom FailureApp implementation that allows a user to add their own controller to handle failures.

Extending or Customizing Devise?

• If you’re looking to extend its authentication functionality: The Model API is the easiest way (and if you’re looking to make an OS contribution, its documentation could use some help)
• If you’re looking to change how the user authenticates: A custom controller may be the easiest way to go.
• If you’re looking to add some data to the user resource inside the controllers: You might want to take a look at extending the build_resource or update_resource helpers inside devise.
• If you want to change the flash messages: You may want to extend the default hashes that set those messages.
• If you notice a security breach in the gem: please do not open an issue or tweet about the problem. E-mail the team directly so the problem can be handled discreetly.

Maybe someone has already made an extension to do what you want to do:

• devise_invitable: allows registered users to invite other users to your app. Also, if you’re thinking of making a Devise extension of your own, this is a particularly excellent example.
• devise-async: allows you to send asynchronous e-mails through devise.
• devise-two-factor: supports two-factor authentication in Devise, as you often see on banking applications (like the CapitalOne360 app).
• devise_security_extension: assists in satisfying enterprise-level security needs with an application using Devise.

The Future of Devise:

• The main focus will be on keeping it stable, secure, and up to date with the latest version of Rails.
• There won’t likely be new models, but the team would like to implement new pluggable APIs where required to improve extensibility.
• The team would also like to see more documentation for both the public and the private APIs. Developers of the world, feel free to contribute here!

Hopefully, you now know more about Devise than you did. Like all open-source projects, Devise is not a black box—and we, as developers looking to improve our craft, should avoid the seductive trap of treating it as such. Happy coding!

And find Lucas online at @lucasmazza.