How to determine if the email was created via rodauth or via the rodauth(:internal) config.

[Halvanhelv]

Hi @janko

I have a registration system where, when creating an account, the user immediately enters a username and password. After email confirmation, the user is automatically authenticated, and no further actions are required. However, the system also allows inviting users, and for these users, after email confirmation, they should be able to enter a password on the verification page.

The issue is that on the current template, I don't display this page, using a loader and JS for automatic confirmation. This behavior shouldn't work for invited users, and I want to understand how to differentiate whether the user was created through rodauth or invited via rodauth(:internal).

Thanks for your help!

Should I duplicate the entire template to handle both cases, or is there a more efficient way to manage this?

<% need_password = rodauth.verify_account_set_password? %>
<% set_meta_tags(title: "Please verify your account", description: rodauth.verify_account_resend_explanatory_text) %>

<%= form_with url: rodauth.verify_account_path, method: :post, data: { turbo: false, controller: need_password ? "" : "rodauth--auto-submit" }, class: "w-full max-w-sm flex justify-center items-center h-auto mt-40" do |form| %>

  <% unless need_password %>
  <div class="loader"></div>
  <% end %>


  <% if need_password %>
    <div class="mb-6 form__group">
      <%= form.password_field rodauth.password_param, value: "", id: "password", autocomplete: rodauth.password_field_autocomplete_value, required: true, class: "#{"form__input-errored" if rodauth.field_error(rodauth.password_param)}", placeholder: rodauth.password_label %>
      <% if rodauth.field_error(rodauth.password_param) %>
        <%= content_tag(:p, rodauth.field_error(rodauth.password_param), class: "form__error") %>
      <% end %>
    </div>

    <% if rodauth.require_password_confirmation? %>
      <div class="mb-6 form__group">
        <%= form.password_field rodauth.password_confirm_param, value: "", id: "password-confirm", autocomplete: "new-password", required: true, class: "#{"form__input-errored" if rodauth.field_error(rodauth.password_confirm_param)}", placeholder: rodauth.password_confirm_label %>
        <% if rodauth.field_error(rodauth.password_confirm_param) %>
          <%= content_tag(:span, rodauth.field_error(rodauth.password_confirm_param), class: "form__error") %>
        <% end %>
      </div>
    <% end %>
  <% end %>

  <div class="form__actions">
    <%= form.submit "Verify account", class: "btn btn-primary btn-block btn-sm", type: "hidden" %>
  </div>
<% end %>

class RodauthInternal < RodauthBase
  configure do
    enable :internal_request, :create_account, :verify_account

    verify_account_set_password? true
    require_password_confirmation? true
    login_param "email"

    after_create_account do
      ActiveRecord::Base.transaction do
        Profile.create!(account_id: account_id, full_name: param("email"))
        Organization.create!(account_id: account_id, name: "#{param("email")}'s Organization")
      end
    end

    create_verify_account_email do
      RodauthMailer.verify_account(self.class.configuration_name, account_id, verify_account_key_value)
    end
  end
end

[janko]

If you're requiring registered users to set a password on account creation, and invited users on account verification, could you just check whether the user has a password set?

need_password = !rodauth.has_password?

Any particular reason you have a separate Rodauth configuration with only the internal request settings? You can check for internal_request? or use internal_request_configuration in your primary Rodauth configuration.

[Halvanhelv]

Thank you for your suggestions. I have the following question:
Is it possible to make Rodauth use a different configuration instead of the primary one, where I can define a separate set of rules (e.g., enabling require_password_confirmation and other specific settings for invited users)? In other words, is there a way to dynamically switch between configurations?

Additionally, if I replace the condition:

<% if rodauth.require_password_confirmation? %>

with

<% if need_password %>

the second password field does appear, but it seems to be ignored even if the value does not match the first password field.

I’d appreciate any recommendations on the best way to handle this!

because the main configuration is being used with

    create_account_set_password? true
    require_password_confirmation? false
    verify_account_set_password? false

[Halvanhelv]

The most extreme option is to send a password in an e-mail for these types of users, but I would like to avoid this if possible.

[janko]

In other words, is there a way to dynamically switch between configurations?

You need to determine the conditions for switching between Rodauth configuration in your controllers/views. Nothing is stopping your from overriding the #rodauth controller method to auto-select the desired Rodauth configuration. This method is only used by your code, rodauth-rails itself doesn't use it.

class ApplicationController < ActiveRecord::Base
  def rodauth(name = nil)
    if some_condition
      super
    else
      super(:invited)
    end
  end
end

the second password field does appear, but it seems to be ignored even if the value does not match the first password field.

Yes, that's because the Rodauth route only validates the password confirm param value if require_password_confirmation? returns true at the time of processing the form submission. In other words, the view template should always display the password confirm field based on rodauth.require_password_confirmation?, and you should be overriding this configuration method instead to change default value.

[Halvanhelv]

The idea of overriding the method:

def rodauth(name = nil)
  if some_condition
    super
  else
    super(:invited)
  end
end

did not work as expected because rails_account was not accessible.

However, fortunately, the following approach seemed to work in RodauthMain:

create_account_set_password? { !rails_account.invited? }
require_password_confirmation? { rails_account.invited? }
verify_account_set_password? { rails_account.invited? }

and RodauthInvited will now only be needed for:

   after_create_account do
   rails_account.update!(account_type: "invited")
   end

I'll test everything tomorrow

PS: do I understand correctly that RodauthMain is fundamentally responsible for handling web requests even if the conditional account was created via RodauthInvited?

I guess I thought that each configuration was a separate closed full cycle entity, but now I realize a little bit that this is not quite true

Thank you for your time and help.

[janko]

By default, Rodauth configurations don't have any separation. While Devise mappings assume separate database tables & session data, Rodauth configurations will share everything unless specified otherwise. For example, if you want separate session data, you need to set session_key_prefix in your secondary configuration. There is no tracking which account was created under which configuration.

That's why it sound to me like it would make sense for you to have everything under the same Rodauth configuration. Because these don't look like conceptually different account types to me (e.g. normal user vs internal admin), a directly registered user and an invited user are probably treated the same after account verification, correct?

I recommend moving this hook into your main configuration, and just adding a conditional:

after_create_account do
  rails_account.update!(account_type: "invited") if internal_request?
end

If you wanted to be more explicit, you could require passing a parameter to make it clear that this is a process of invitation:

RodauthApp.rodauth.create_account(..., params: { "action" => "invite" })

after_create_account do
  if internal_request? && param("action") == "invite"
    rails_account.update!(account_type: "invited")
  end
end

[janko]

Signs when you probably want to use different Rodauth configurations:

• it's a different account type that requires fundamentally different authentication configuration
  • e.g. normal users can self-register, but internal admins can only be created manually from the console
  • e.g. for normal users 2FA is optional, but for internal admins 2FA setup is required
• you want to permanently differentiate them in the database
  • e.g. an accounts.type column or entirely separate table
• you want to track login state separately, possibly allowing both account types to be logged in at the same time

[Halvanhelv]

it makes sense, but I don't quite understand about the admin example?

If admin is a very different entity, how will rodauth use other configuration settings? via prefix and session_key_prefix?

[Halvanhelv]

I've also noticed that if I try to create through the

RodauthApp.rodauth.create_account(..., params: { “action” => “invite” })
it complains that there's no password, apparently because

create_account_set_password? { !rails_account.invited? }
is called before after_create_account

[janko]

If admin is a very different entity, how will rodauth use other configuration settings? via prefix and session_key_prefix?

Yeah, in that case you'd probably have an /admin path prefix to the admin authentication routes, so Rodauth would pick the :admin configuration when processing those. Without the path prefix, it would choose the configuration with which r.rodauth was called in the Rodauth app's route block.