This is not meant to be a system where all factors are accounted for. User is the most common model name for the credentials holder. An account has_many users, but adding an account model is an exercise for the programmer.

Add --allow-resets which will add a reset password controller/mailer

Maybe, it would be more sensible to generate resets by default, and have --without-resets option or don't have that option at all. Shouldn't be to hard to remove it from the generated code if necessary

Genuine questions: why use a separate Session model over the build in session store (by default CookieStore)?

@smitssjors Because then you can do session indexes, alert when new sessions are created from unknown locations, do statistics on user agents, etc. Session tokens in the DB with a drip of metadata is a wonderful pattern for all of this, and something the majority of applications should use.

Actually, will tackle the idea of a password reset mailer/flow as a separate upgrade, if necessary. There are a significant number of views involved with that flow. On the fence about whether that's a good fit for a generator like this.

Unrelated test failures (again!).

Wdyt about enabling automatic squashing when merging PRs?

Why store a long string in database and then run a sequential find by query for finding a Session? @dhh

Why can't we use signed_id for this purpose here so that the look up would be done using the integer primary key?

So, we can drop the token column for sessions and instead of doing

Session.find_by(token: token)
# and 
cookies.signed.permanent[:session_token] = { value: session.token, httponly: true, same_site: :lax }

we could do

Session.find_signed(token)
# and 
cookies.signed.permanent[:session_token] = { value: session.signed_id, httponly: true, same_site: :lax }

PR => #52504

Could it be possible to change what id is for us who prefer uuid v4, without hassle with migrations? The generator seems to assume everyone uses sequential bigint for ids.

mongo?

This is not meant to be a system where all factors are accounted for. User is the most common model name for the credentials holder. An account has_many users, but adding an account model is an exercise for the programmer.

I agree with the user but I'm wondering why you choose email_address over email as the default