Sorcery VS Devise

I have been using devise for a while and it has consistently given me issues. I have wistfully been staring at sorcery for a while now but cant justify the switch since devise is already in the project.

I made a 8 minutes video tutorial (following the wiki: https://github.com/Sorcery/sorcery/wiki/Simple-Password-Authentication) to introduce how to build a simple password authentication feature with Sorcery. With some minor modification to please Turbo.

We'll be installing Sorcery based off this tutorial in their wiki. I'm modifying a little bit since we are creating something different, but also because their tutorial is a bit outdated since it is based off an older version of Rails.

But does it have to be so soon? There are other areas where I'm just as ignorant as I was about the inner workings of authentication (see "the database" below), and in these areas there's not a gem that can automatically solve the problem for me—which is what I've ended up doing for authentication in my own project: even though I could build authentication from scratch, instead I'm using an authentication gem because the effect is exactly the same, but with less code in my app for me to maintain. (Rather than Devise, I've chosen the more lightweight alternative Sorcery. It's simple enough that I can still understand and control the authentication flow, while also providing enough conveniences that I don't have to write out implementation details from scratch.)

Also Sorcery is, despite its name, a little less magic than Devise.

sorcery

ActiveRubyist is now a Progressive Web App (PWA) with Hotwire-based interactivity. For authentication, I use devise, and for real-time notifications, noticed. Where possible, I lean into default Rails features: for background jobs, I use Solid Queue instead of Sidekiq, keeping everything aligned with the Rails way.

Assume we use devise for authentication. We need to subscribe user for personal notifications channel. Add this line to app/views/layouts/application/_flash_container.html.erb

To add, the above code is a pretty near approximation of the literal code inside the devise codebase, which is a very standard Ruby auth system.

See here:

https://github.com/heartcombo/devise/blob/main/lib/devise/co...

        def self.define_helpers(mapping) #:nodoc:

In October 2024, I presented at the Toronto Ruby Meetup on discovering the potential of using Lockable. Devise is a popular authentication library that provides ready-made solutions for user authentication. One of the features it offers is Lockable, which is used to lock a user account after a certain number of failed login attempts. This feature helps improve security by preventing brute force attacks.

Acknowledging that I haven't had a chance to try the new Rails 8 auth stack... over the last decade I've gone from being a Devise hater to a Devise lover.

Yes, it can seem esoteric and magical (in the bad way) until you wrap your head around the idioms and design philosophy. There's a lot of functionality that happens unless you override it. I fully get that this rubs a lot of people who aren't in the pool the wrong way.

However, in addition to the impressive selection of modular capabilities mentioned elsewhere in this thread, there's a very bright light that goes on when you realize that you can make powerful changes to the way the library works by reopening a few controller classes and defining your own methods.

My strong advice for anyone looking at Devise and perhaps feeling stumped is to open up https://github.com/heartcombo/devise/tree/main/app/controlle... and spend some tens of minutes looking at how the library does what it does. These controller - especially sessions and registrations - contain all of the business logic driving the "magic". Not only do they reveal themselves as relatively simple and well thought out, all of those yield calls mean that you can call those methods while passing a block to them. Whatever is in that block will be evaluated inside of that method when it runs.

The people who designed Devise put a lot of thought into this stuff. When you get it, you suddenly don't want to be without it.

However, using ActionController::Live can sometimes lead to unexpected issues, particularly with authentication libraries like Devise. Devise may raise errors when ActionController::Live is active, especially related to the session or Warden errors, as discussed in this GitHub issue. This happens because ActionController::Live opens a separate thread for streaming, which can cause conflicts with Devise’s thread safety and session handling.

If you like to know how to implement Devise for user authentication, here's the link- Devise

Use devise gem, which is probably the most famous rails authentication system.

IMHO the stateful opaque token approach is simple enough that it can (and often does) get baked into whatever language/framework you’re using to write your app. In addition, the very nature of session tokens is such that the logic for what the token actually means/represents lives in your app, on the server.

So, that may be why we don’t see more “opaque session token” standards/libraries out there as an alternative to JWTs.

But if you want an existing example, Devise for Rails [1] has been around a while.

[1] https://github.com/heartcombo/devise

Users can signup and login via the Devise gem and create their organizations.