Sorcery VS rails-ujs

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

GitHub/rails-ujs

Prior to Rails 7, when you would want to log out or destroy a resource (a post or image), you would write <%= link_to "Sign out", destroy_user_session_path, method: :delete %>. The method: :delete part relied on an old library, rails-ujs and it helped make NON-Get requests from hyperlinks. Now with Turbo, the solution is to add data: { "turbo-method": :delete } so you don't get an error saying the link_to helper was looking for a GET resource. However, Turbo is not handling the redirect as we expect it, or at all, we need to explicitly say we want a 303 redirect so we add status: :see_other as an option in our destroy action.