Using Rodauth::Rails.rodauth as an "API"

[bjeanes]

Hey @janko,

This is a continuation of the discussion that started on Reddit last November, which I believe prompted you to add Rodauth::Rails.rodauth.

In that thread, I linked to a gist which demonstrated what I was doing to new up a Roduath auth class instance as an API.

Today, I finally have tried to switch to using your upstream method and immediately hit a few obstacles. I was going to open a GH issue initially (which I still may do) but also wanted to re-visit the larger discussion.

First up, the issues I hit with trying to use Rodauth::Rails.rodauth:

• Anything which calls session raises:

  > Rodauth::Rails.rodauth(:user).session
  Roda::RodaError: You're missing a session handler, try using the sessions plugin.
  from /bundle/gems/roda-3.44.0/lib/roda/request.rb:375:in `session'

• Anything which calls param or request.params raises: RuntimeError: Missing rack.input

   > Rodauth::Rails.rodauth(:user).param("login")
   RuntimeError: Missing rack.input
   from /bundle/gems/rack-2.2.3/lib/rack/request.rb:442:in `POST'

Obviously, we are not in a real request setting and I understand that setting a session value (non-cookie session stores aside) won't have any end effect for a user. However, given how much of Roda internals are side-effecting, it isn't practical to be able to call any useful internal methods without touching things like the session.

Furthermore, unless one creates a separate slimmer config for API usage (and consequently risks bugs due to inconsistencies with the primary config), inevitably there will be before_*/after_* hooks which may read params or read&write session store.

Lastly, Rodauth core features vary with regard to using account_id and using session_value (sometimes for good reason and other times perhaps for historical reasons--I'm not sure). This poses a very real need to address the session store situation and perhaps even pre-filling its contents.

In the Reddit thread, you had picked up on my account_from_id auth method, which merely sets @account = account_ds(id).first, but I've found I also need to have session[session_key] = id set, so that features using session_value are functional. Another example I've encountered is with active_sessions feature where the active_sessions_ds is defined in terms of session_value, causing me grief when wanting to delete a user's active sessions after an admin changes the email address. This comes up regularly with compromised accounts (for which we allow users to prove their identity to regain access).

Anyway, I was able to work around the params issue by mutating the internal Rack env, like so:

rodauth = Rodauth::Rails.rodauth(configuration_name)
rodauth.scope.env.merge!({
  Rack::QUERY_STRING => "",
  Rack::RACK_REQUEST_QUERY_STRING => "",
  Rack::RACK_REQUEST_QUERY_HASH => {},
  Rack::RACK_REQUEST_FORM_HASH => {},
})

I think setting the query string and form hash out of the box makes sense.

NOTE: in my usage, I actually am passing non-empty params and encoding to query string with URI.encode_www_form, because I have hooks which do things like read param(login_param) during audit log metadata (i.e. to capture old and new logins). Without having a separate config, I need to contend with this during "API" usage too. I've run into this need often enough, that there is a case for improving Rodauth::Rails.rodauth to accept params out of the box, but we can defer that discussion.

For the issue with touching session, I don't understand it and hitting that after fixing the params issue is what led me to leave this post. It gets really into the weeds with my understanding of the separation between Roda and Rodauth.

---

Now, as for the broader discussion of "programmable Rodauth"...

There are certainly things which rodauth-rails could do to make this use-case better, but I think there are some real challenges in the current spelling of Rodauth internals that would require a larger and serious discussion involving Jeremy.

Chiefly is the issue of the atomicity around before_x, x, after_x. Rodauth's out of the box auditing functionality relies on after_* being called, for one, and custom config in either before_* or after_* might affect the behaviour of the unit as a whole (perhaps by throwing, raiseing or altering state). Clearly, if an admin changes a users email this can't be done in the request's Rodauth instance or it will have side effects for the admin's session, so it must be done in a quarantined and virtual instance a la Rodauth::Rails.rodauth and I don't think anybody would argue that this shouldn't also leave an audit trail.

However, we wouldn't want to simply duplicate the before_x, x, after_x triplets inside other API because sometimes they are not so simple, such as change_login being fallable and after_change_login not running in that condition.

Ultimately, I think we can make Rodauth nice to use for these out-of-request use cases without Jeremy's support to de-couple the core stateful changes from the request life-cycle as a whole. By stateful here, I don't mean things like @account so much as things like inserting a password hash into the DB. Ideally, all features would be re-worked to be a discrete API and the Roda-exposed feature routes would use the same API as would a use case outside of that request. That's big work and I'm not sure Jeremy would even be interested in a move in that direction.

Personally, this is the primary (and almost only) grievance I have with Rodauth as a whole. It has the best-designed data model of anything in Rubyland but hasn't really accounted for the use cases that would exist to support the human beings who are the users in that data model.

[janko]

Hi @bjeanes, thanks for continuing this discussion 👍🏻

Based on what you said, it seems that making methods like #param and #session work would solve most of the problems. It's reassuring that setting certain Rack env values solved the params problem, then the developer can handle empty params in hooks and other rodauth settings. The session shouldn't be difficult to solve, I think setting rack.session env key to an empty hash would do the trick (though it's probably a bit more involved than that).

As for the account ID in the session, I'm thinking about an :account keyword argument, which would accept an Active Record model instance, and set both @account and session[session_key] on the returned Rodauth instance.

So, for current account, params, and session, the Rodauth::Rails.rodauth method could be extended with the following:

Rodauth::Rails.rodauth # account, params, and session are empty
Rodauth::Rails.rodauth(params: { foo: "bar" }) # set mock params
Rodauth::Rails.rodauth(account: Account.find(account_id)) # set @account and session[session_key]
Rodauth::Rails.rodauth(session: { two_factor_auth_setup: true }) # set mock session
Rodauth::Rails.rodauth(env: { ... }) # add more values to Rack env hash

---

Regarding not having to call before_* and after_* hooks manually when calling Rodauth operations, provided that hooks are named the same as the operation (which isn't always the case), one could have a wrapper method like #call, where call(:something) would call before_something, something, and after_something. I remember exploring that a few months ago, and working on a few improvements in the Rodauth internals to support that better (mainly extracting some operations), I would like to pick it up again. Is that something that would improve the situation?

I also wanted to mention that over the past several weeks I've been working on a mixin for the account AR model, which defines a password attribute & validations (that work regardless of whether the password hash is stored in a column or a separate table), and associations for feature tables. This would simplify inserting the password hash (account.password = "secret") or deleting the account's active sessions (account.active_session_keys.delete_all). I'm still not 100% sure it's the right path, mainly whether it won't open a slippery slope regarding how much of Rodauth functionality should be supported through the Active Record model, but hopefully it won't.

[janko]

I've just opened a thread on the rodauth google group to discuss this, so we can go from there 🙂

[janko]

I've ran across some issues when trying to support controller callbacks running around internal requests. The problem is, in order to assign rodauth instances in rack env, I would need to assign instances of the internal subclasses of rodauth classes. Otherwise the regular rodauth instances complain that they are missing things from env, such as the session handler.

I gave it some thought, and I actually don't think controller callbacks should run at all during internal requests. An internal request is not an actual request, it's a programmatic call to the Rodauth API, it just happens to be implemented as a rack request internally. Not running callbacks could cause issues with view rendering, as templates might rely e.g. on instance variables set in the callbacks, but we should be able to avoid it by skipping view rendering altogether during internal requests (the rendered HTML is not used anyway AFAICT).

How does that sound? Do you see any issues in skipping callbacks during internal requests?

[bjeanes]

That's amazing--I had the same exact same thought while tossing around in bed restlessly last night.

I entirely agree. If rodauth-rails is able to just step aside for these internal requests, I think that's entirely workable. Huge +1

[janko]

Great, so here is the PR that adds support for internal requests – #53. With these changes I was able to successfully send internal requests in the demo app. Please test it out and let me know if anything is missing.

[bjeanes]

Will do! I just bought a house yesterday so I can't promise it will get my attention before next week, but I'll try to take a close look ASAP.