Multi-tenancy: account_login_filter

[pboling]

Did the idea for supporting multi-tenancy discussed in this google groups thread in 2021, which involved adding a new feature hypothetically called account_login_filter, ever become reality? I am not able to find that exact method name in the code base, but perhaps when it was added it was named something else.

[janko]

The account_table_ds private method got added, which is shared by account_from_login and account_from_session, as well as retrieval of accounts from tokens. I believe you could use it for multi-tenancy. Taking the example from the google group thread:

auth_class_eval do
  private
  def account_table_ds
    super.where(tenant_id: request.env[:tenant_id])
  end
end

[jeremyevans]

This may be specific to rodauth-rails and not Rodauth itself, as I'm not aware of Rodauth itself creating a Rodauth instance with a nil scope.

[janko]

The mailer in rodauth-rails retrieves the account using a Rodauth object without a Roda scope, because it can be run in a background job, where there is no request context.

If the primary key (id) is unique across all tenants, then I would suggest just skipping the filter when there is no request:

def account_table_ds
  if request
    super.where(tenant_id: request.env[:tenant_id])
  else
    super
  end
end

Alternatively, you can pass the tenant ID down to each mailer method, and set the Roda scope with it:

class RodauthMain < Rodauth::Rails::Auth
  configure do
    create_reset_password_email do
      RodauthMailer.reset_password(account_id, request.env[:tenant_id], reset_password_key_value)
    end
    # ...
  end
end

class RodauthMailer < ApplicationMailer
  def reset_password(account_id, tenant_id, key)
    @rodauth = rodauth(account_id, tenant_id) { @reset_password_key_value = key }
    @account = @rodauth.rails_account

    mail subject: @rodauth.reset_password_email_subject
  end
  # ...
  private
  def rodauth(account_id, tenant_id)
    instance = RodauthApp.new({ tenant_id: tenant_id }).rodauth
    instance.instance_eval { @account = account_ds(account_id).first! }
    instance.instance_eval(&block) if block
    instance
  end
end

[pboling]

Thanks for that explanation @janko ! You've just made me realize why I need to do something, and that what I just pushed has a bug. The URL that will be in the mailer for account activation won't have the "tenant_id" in it, and we are using that as a "path key" in the route/path for our multi-tenancy. So I'll need to, at minimum, fix the verify-account path generation to include the tenant_id. I'd have the same problem with any other emails that generate paths for links back to the API, and also for the UX path helpers.

Is there an idiomatic way to have path generation be account-context dependent, so the tenant_id can be derived and injected into the path?

[pboling]

It appears I will have to redefine the built-in paths, using the path plugin and redefining them with my desired prefix, and dynamic tenant path key.

Here's what I have now for multi tenancy, which works perfectly when the right routes are called, with the exception of the incorrect paths used in the mailer templates. Also I don't know how to programmatically generate any of these routes, as would be needed for the mailer templates, and for automated request specs.

class RodauthApp < Rodauth::Rails::App
  configure RodauthMain
  plugin :shared_vars
  plugin :symbol_matchers

  symbol_matcher :path_key, /([A-Z0-9_-]+)/xi

  route do |r|
    r.on("api") do
      r.on("auth") do
        r.on(:path_key) do |path_key|
          tenant = Tenant.fetch_by_path_key(path_key)

          r.on(proc { tenant }) do
            shared[:tenant] = tenant
            shared[:path_key] = path_key
            r.env[:pk_tenant_id] = shared[:tenant].id
            r.rodauth
          end
        end
      end
    end
  end
end

Is it insane to nest rodauth this way?

[janko]

Nesting looks fine, but the shared_vars Roda plugin probably isn't doing anything, because it's intended for sharing data between Roda apps, but you have only one in your Rails app. The path plugin would likely be an overkill as well, because it won't be used by Rodauth's route helpers anyway.