Why there is no simple default auth in Rails?

andreyazimov · September 20, 2021, 9:36am

Hello, I’m a Rails newbie.

I wonder why there is no simple auth (sign-in, sign-up, restore password) in the Rails app?

I found that I need to use devise but it’s too complicated for me, and would be much nicer to add auth option for new rails apps like:

rails new my_app --auth

The same like in Laravel.

Also, devise is not supported yet in Rails 7 yet? (I might be wrong).

Thanks.

collimarco · September 20, 2021, 1:43pm

Devise is the de-facto standard for Rails and it’s simple to use:

https://github.com/heartcombo/devise#getting-started

We’ve been using it for 10+ years without any problems and it will certainly support Rails 7.

Deck · September 21, 2021, 8:25am

He is not wrong though? It still would be nice having a quick generator for doing auth? Rails is known for having bunch of useful generators actionmailer, activestorage

This something that been coming up time and time again for a very long time. What’s even crazy here is that many of the rails alternative and some of them even rails-inspired are nowadays offering a quick way scaffolding auth.

collimarco · September 25, 2021, 12:33pm

This is the bug with Rails 7:

https://github.com/heartcombo/devise/pull/5397

You can comment there.

Pito · September 27, 2021, 5:12pm

I so agree with this. For some reason #DHH has decided that login, authentication, user management, etc. are all outside the scope. But basically every single rails app has that (which you can’t say about document uploading (active storage), emailing (active mail), and other built-ins. And pointing to devise doesn’t do it for me. Last I tried (and based on more recent blogs etc.) devise is not for everyone, it is very (overly) complicated for most apps. But I asked this question on this site (or another one) several years ago and was told to forget about it, it’s never gonna happen.

e_a · September 27, 2021, 6:05pm

I think the question is not “does every app need this feature” but “is there a single solution for this feature that will work for most apps”. Things like file storage (ActiveStorage), email (ActiveMailer), etc the answer is generally yes.

Sure there are other solutions. For example we have Paperclip, Dragonfly, Carrierwave, etc for file storage. But ActiveStorage can be a solution that will work for most applications.

For authentication the answer is different. Authentication gets complicated and divergent quickly. Are you even using passwords or are you authenticating via email (like Medium). Do you allow social logins? If so which ones? What about enterprise identity management systems like ActiveDirectory? Do you support 2FA? If so which ones? TOTP? Hardware key? What about security? Should the authentication rate limit? Lockout after a certain amount of attempts? Validate your password is a certain length? Validate it’s not a dictionary word?

There are so many questions and answers to these question that there isn’t one solution to satisfy most apps. For an internal app HTTP Auth with hard-coded credentials might be sufficient. For other apps they don’t want the responsibility of dealing with credentials so only social logins are supported. Other apps want to outsource it to a provider like Auth0.

Because of this goal diversity a marketplace of options is probably best. My list is:

HTTP Auth - Toy/Internal apps. This is actually built-in to Rails!
Omniauth - Social-login focused (although there is a user/pass provider)
Devise - A kitchen sink of many features you likely want (and probably a few you don’t)
Auth0 - Enterprise apps that need integration with things like ActiveDirectory

petrik · September 30, 2021, 4:18pm

There also is Clearance from Thoughtbot: https://github.com/thoughtbot/clearance/

Deck · October 8, 2021, 6:12am

A simple db auth should be provided by the web framework. If you want social auth that’s when you maybe should start looking into gems that handle this things.

I found two frameworks that I follow that have both included some kind of auth-system

https://github.com/redwoodjs/redwood/pull/2701

ksouthworth · November 19, 2021, 7:01pm

I think this is exactly the point. Rails should have an out of the box solution for user authentication that will work for most applications.

Just like you can choose to use Shrine instead of ActiveStorage when you have different requirements than the built-in stuff offers.

I totally agree Rails should come with a “batteries included” user authentication feature.

The fact that devise has been the de-factor standard for 7+ years and HASN’T been folded into Rails core in some capacity still seems strange to me.

strzibny · February 4, 2022, 9:54am

I believe Devise might be too big and complex for being a default. But just my guess;)

jonathanhefner · February 4, 2022, 10:10pm

There are many ways in which an authentication system can be bespoke. (Just look at all of the ways Devise can be configured!) I believe the aversion to a default authentication system is based on the desire to encourage developers to design a system that is right for their app.

With that in mind, I’ve submitted a few PRs that I hope could make it nicer to implement a bespoke system:

github.com/rails/rails

Support password challenge via `has_secure_password`

rails:main ← jonathanhefner:has_secure_password-password_challenge

opened 04:17PM - 22 Nov 21 UTC

jonathanhefner

+95 -22

This enhances `has_secure_password` to define a `password_challenge` accessor an…d the appropriate validation. When `password_challenge` is set, the validation checks that it matches the currently *persisted* `password_digest` (i.e. `password_digest_was`). This allows a password challenge to be implemented with the same ease as a password confirmation, re-using the same error handling logic in the view, as well as the controller. For example, in the controller, instead of: ```ruby password_params = params.require(:password).permit( :password_challenge, :password, :password_confirmation, ) password_challenge = password_params.delete(:password_challenge) @password_challenge_failed = !current_user.authenticate(password_challenge) if !@password_challenge_failed && current_user.update(password_params) # ... end ``` One could write: ```ruby password_params = params.require(:password).permit( :password_challenge, :password, :password_confirmation, ).with_defaults(password_challenge: "") if current_user.update(password_params) # ... end ``` And, in the view, instead of checking `@password_challenge_failed`, one could render a password challenge error in the same manner as other form field errors, including utilizing `config.action_view.field_error_proc`. --- Tangential: #43689, #43690

github.com/rails/rails

Add `:errors` option to `form_with`

rails:main ← jonathanhefner:form_with-errors-option

opened 04:36PM - 22 Nov 21 UTC

jonathanhefner

+114 -59

This option allows developers to specify an errors object for a form independent…ly of specifying a model. This allows forms which aren't backed by a model to utilize `config.action_view.field_error_proc`. This is also useful for forms that should not be pre-populated, but that should still display validation errors. For example, a "change password" form like: ```erb <%= form_with(url: change_password_path, scope: :password, model: current_user) do |form| %> <%= form.label :password_challenge, "Current password" %> <%= form.password_field :password_challenge, value: "" %> <%= form.label :password, "New password" %> <%= form.password_field :password, value: "" %> <%= form.label :password_confirmation, "Confirm new password" %> <%= form.password_field :password_confirmation, value: "" %> <%= form.submit "Change password" %> <% end %> ``` Could be written as: ```erb <%= form_with(url: change_password_path, scope: :password, errors: current_user.errors) do |form| %> <%= form.label :password_challenge, "Current password" %> <%= form.password_field :password_challenge %> <%= form.label :password, "New password" %> <%= form.password_field :password %> <%= form.label :password_confirmation, "Confirm new password" %> <%= form.password_field :password_confirmation %> <%= form.submit "Change password" %> <% end %> ``` --- Tangential: #43688, #43690

github.com/rails/rails

Add `ActionController::Parameters#require_slice`

rails:main ← jonathanhefner:strong_parameters-required_slice

opened 04:53PM - 22 Nov 21 UTC

jonathanhefner

+59 -18

This method behaves like `slice`, but raises `ParameterMissing` if any of the sp…ecified keys are missing. Additionally, the specified params are marked as permitted, but any nested params are not. e.g. `params.require_slice(:foo, :bar).require(:foo)` is the same as `params.require(:foo)`, regardless of what the `:foo` param is. This method is useful for permitting and requiring multiple keys. It is also useful for permitting top-level (unscoped) params without triggering the `action_on_unpermitted_parameters` action due to incidental params like `authenticity_token` and `commit`. For example, "change password" params implemented like: ```ruby def password_params params.require(:password).permit( :password_challenge, :password, :password_confirmation, ).with_defaults(password_challenge: "") end ``` Could instead be implemented like: ```ruby def password_params params.require_slice( :password_challenge, :password, :password_confirmation, ) end ``` --- Tangential: #43688, #43689

github.com/rails/rails

Add authenticate_by when using has_secure_password

rails:main ← jonathanhefner:authenticate_by

opened 06:00PM - 02 Dec 21 UTC

jonathanhefner

+154 -1

This method is intended to replace code like the following, which returns early …when a user with a matching email is not found: ```ruby User.find_by(email: "...")&.authenticate("...") ``` Such code is vulnerable to timing-based enumeration attacks, wherein an attacker can determine if a user account with a given email exists. After confirming that an account exists, the attacker can try passwords associated with that email address from other leaked databases, in case the user re-used a password across multiple sites (a common practice). Additionally, knowing an account email address allows the attacker to attempt a targeted phishing ("spear phishing") attack. `authenticate_by` addresses the vulnerability by taking the same amount of time regardless of whether a user with a matching email is found.

github.com/rails/rails

Add `ActiveRecord::Base::normalizes`

rails:main ← jonathanhefner:active_record-normalizes

opened 06:25PM - 20 Dec 21 UTC

jonathanhefner

+306 -1

This method can be used to declare normalizations for attribute values. Normali…zations are applied when attributes are assigned or updated, and the normalized values will be persisted to the database. Normalizations are also applied to matching keyword arguments of finder methods. This allows a record to be created and later queried using an unnormalized value. For example: ```ruby class User < ActiveRecord::Base normalizes :email, with: -> email { email.strip.downcase } end user = User.create(email: " CRUISE-CONTROL@EXAMPLE.COM\n") user.email # => "cruise-control@example.com" user = User.find_by(email: "\tCRUISE-CONTROL@EXAMPLE.COM ") user.email # => "cruise-control@example.com" user.email_before_type_cast # => "cruise-control@example.com" ```

github.com/rails/rails

Add `ActiveRecord::Base::generates_token_for`

rails:main ← jonathanhefner:active_record-generates_token_for

opened 06:10PM - 17 Jan 22 UTC

jonathanhefner

+281 -0

Currently, `signed_id` fulfills the role of generating tokens for e.g. resetting… a password. However, signed IDs cannot reflect record state, so if a token is intended to be single-use, it must be tracked in a database at least until it expires. With `generates_token_for`, a token can embed data from a record. When using the token to fetch the record, the data from the token and the data from the record will be compared. If the two do not match, the token will be treated as invalid, the same as if it had expired. For example: ```ruby class User < ActiveRecord::Base has_secure_password generates_token_for :password_reset do # BCrypt salt changes when password is updated BCrypt::Password.new(password_digest).salt[-10..] end end user = User.first token = user.generate_token_for(:password_reset) User.find_by_token_for(:password_reset, token) # => user user.update!(password: "new password") User.find_by_token_for(:password_reset, token) # => nil ``` --- This fleshes out https://github.com/rails/rails/pull/43620#issuecomment-975766450. Closes #43620. Possible follow-ups: - Support an `unsigned: true` option to avoid message signing overhead for non-public tokens (e.g. session tokens). - Enhance `has_secure_password` to also generate a `password_salt` method. - Add options to `MessageVerfier` to embed "created at" time instead of "expires at" time in the message. This would allow `generates_token_for` to precisely expire only tokens that were generated before the current `expires_in` time window, rather than invalidate all tokens that were generated with a different `expires_in`. (Perhaps this could look something like `verifier.generate(..., expires_later: true)` and `verifier.verify(..., max_age: 15.minutes)`.)

They haven’t gotten much traction yet, but feedback is welcome.

I have a few more ideas for features I would like to see (such as automatically re-hashing a password on login if the BCrypt cost has changed), but I’m not yet sure how to make them suitable for Rails. For anyone who has implemented their own bespoke authentication system: what would make your code nicer?

adwb · October 8, 2022, 7:45pm

Just found this thread. I think including a auth framework would make starting new apps easier but it would encourage folks to leave the defaults and deploy insecure apps. WordPress is an example of a super popular framework that is so easy to deploy and it’s the most hacked web app because of that. I think by forcing us to implement auth Rails encourages better security practices. Just my two cents.