Requiring account in application code

[janko]

Sometimes it can happen that the logged in account doesn't exist in the database anymore. For me a common scenario is manually deleting the account in development as a quick way to start fresh, but I can imagine staging/production scenarios where an account gets deleted by the system for various reasons.

In rodauth-rails, the #current_account controller/helper method is currently handling this scenario in the same way as Rodauth's #require_account_session method. Now, I've since found a way to reuse #require_account_session instead of duplicating its logic, but I realized that performing a redirection can be unexpected for a #current_account method either way.

I noticed that both #require_account_session and #require_account Rodauth methods are private, so I was wondering whether there is another recommended way in Rodauth to handle this scenario in non-authentication routes, or whether trying to do this is considered an anti-pattern. I was thinking it would be useful if #require_account (and maybe even #require_account_session) were public, as then I could recommend using it in Rails instead of #require_authentication/#require_login, since most applications will probably want to retrieve the logged in account in all requests anyway.

Other than handling deleted accounts, I thought it would also be a convenient way to log out accounts whose unverified grace period expired. If I understand correctly, in applications that use #require_authentication/#require_login and retrieve the account straight from the session value, a user could theoretically continue using the app even after the unverified grace period has expired, as long as they don't close the browser and don't use any authentication routes. This sounds like it might be problematic, but maybe I'm mistaken. Being able to call #require_account/#require_account_session would handle that, as #account_from_session won't find accounts whose unverified grace period has expired.

[jeremyevans]

I'm OK with making require_account public. I didn't expect there would be a need for applications to call it, but since there is, there's no issue switching the visibility. We would need to document it in the README.

I would be surprised if most applications need the full logged in account on all requests. I don't have any applications that require that. I don't consider using it an anti-pattern, but extra database checks are going to decrease performance. It might depend on how much performance matters for your application. If you are running Rails, the relative performance hit from extra database checks is going to be less, compared to if you are running Roda. I would certainly not recommend require_account as a default, but I see no problem with explaining the differences and allowing the user to make an informed decision. I think most people that would want to use require_account are the type to use the active_sessions feature, which would automatically handle this issue.

In terms of sessions being inactive after the grace period expires, maybe it would be a good idea to have the verify_account_grace_period set the unverified_account_session_key in the session to the time when the grace period expires, and check that in require_authentication, require_login, or logged_in? (not sure which), clearing the session if the grace period has expired. What are your thoughts on that?

[janko]

Cool, I will send a PR for making #require_account public sometime this week.

I would be surprised if most applications need the full logged in account on all requests. I don't have any applications that require that. I don't consider using it an anti-pattern, but extra database checks are going to decrease performance. If you are running Rails, the relative performance hit from extra database checks is going to be less, compared to if you are running Roda.

Yeah, you're right. I was imagining retrieving things like user's name and profile image, but if those are stored in a separate table, they can be retrieved without retrieving the account object. In Rails, I expect people prefer the convenience of being able to call account's association methods (e.g. Devise's main controller methods all retrieve the account).

In terms of sessions being inactive after the grace period expires, maybe it would be a good idea to have the verify_account_grace_period set the unverified_account_session_key in the session to the time when the grace period expires, and check that in require_authentication, require_login, or logged_in? (not sure which), clearing the session if the grace period has expired. What are your thoughts on that?

This solution sounds good to me. My initial feeling was to use #logged_in?, but I suppose it might be strange that a predicate method can modify state (clearing the session). I'm trying to think of a scenario where handling it in #require_login could cause issues, but I can't think of any. Between #require_login and #require_authentication I would choose the former, mainly so that anyone calling #require_login in their application also benefits from this.

[jeremyevans]

For information displayed on all logged in pages, such as the user name and profile image, I usually just store those in the session, so they don't require a database query on every request. As long as you careful about the sizes, that approach shouldn't present a problem.

I agree that require_login seems best for the grace period expiry checking. Is that something you have time to work on? If not, I can implement it.

[janko]

For information displayed on all logged in pages, such as the user name and profile image, I usually just store those in the session, so they don't require a database query on every request.

That's an interesting approach, thanks for sharing it 🙂

I agree that require_login seems best for the grace period expiry checking. Is that something you have time to work on? If not, I can implement it.

Yes, I should be able to find time this week for this as well 👍🏻