Loading internal_request into a named auth class

[janko]

When testing something in a self-contained script, I noticed that internal_request feature isn't correctly initialized when it's loaded into a named auth class, because at that point the roda_class hasn't yet been set, it doesn't get set on the internal subclass in post_configure.

require "rodauth"
require "sequel"
require "roda"

Sequel.sqlite

class RodauthMain < Rodauth::Auth
  configure do
    enable :internal_request
  end
end

class RodauthApp < Roda
  plugin :rodauth, auth_class: RodauthMain
end

RodauthMain.account_exists?(login: "[email protected]") # fails

/Users/janko/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/rodauth-2.18.0/lib/rodauth/features/internal_request.rb:285:in `internal_request': undefined method `new' for nil:NilClass (NoMethodError)
        from /Users/janko/.rbenv/versions/3.0.1/lib/ruby/gems/3.0.0/gems/rodauth-2.18.0/lib/rodauth/features/internal_request.rb:365:in `block (3 levels) in post_configure'
        from bla.rb:17:in `<main>'

Loading the internal_request works in the plugin block, as at that point the roda class has already been assigned, so that's definitely an alternative.

class RodauthMain < Rodauth::Auth
  configure do
    # ...
  end
end

class RodauthApp < Roda
  plugin :rodauth, auth_class: RodauthMain do
    enable :internal_request
  end
end

In rodauth-rails this is not a problem, because there the roda_class is assigned as soon as Rodauth::Rails::Auth (a subclass of Rodauth::Auth) is subclassed, not only when loading the plugin. I was just considering if this can be addressed in Rodauth somehow, to make internal_request easier to use with named auth classes outside of Rails.

An idea I had was to call post_configure only in Roda's configure plugin hook, which ensures roda_class will be assigned, instead of in Rodauth::Auth.configure. One hiccup there is that if plugin is initialized without a block and a new auth class, #post_configure wouldn't exist, as the base feature isn't loaded. But we could probably fix this by disallowing not passing a block if the auth class is not configured.

What do you think about this?

[janko]

This would also help with potential Rodauth features that load Roda plugins. For example, I'm currently working on an OmniAuth integration for Rodauth, and that feature in post_configure loads Roda's run_handler plugin, along with a custom Roda plugin that adds r.omniauth method for routing OmniAuth requests.

[jeremyevans]

One simple solution for roda_class in internal_request would be to do something like:

module InternalRequestClassMethods
  def roda_class
    superclass.roda_class
  end
end

and drop the setting of the @roda_class instance variable in post_configure. What are your thoughts on that approach? I don't think the performance difference will be an issue.

In terms of changing when post_configure is called, we could only call post_configure if it is defined. I think that would work better than breaking backwards compatibility by adding new restrictions.

[janko]

Thanks, both solutions sound good to me. Given that delaying post_configure will also handle loading Roda plugins in features (when using named auth classes), I will go ahead and submit a PR for that.