0.4.0 configuration preview

Prepare for the expanded configuration file and optional password-signup confirmation in AddAuth 0.4.0.

Generate the configuration file

In a Rails app with the stock authentication files and the published target bundle installed, run:

bin/rails generate add_auth:install

Open config/initializers/add_auth.rb. The 0.4.0 template groups every setting by feature, leaves defaults active and comments out alternatives. Each feature section names its generator and prerequisites. For example, before session adoption:

AddAuth.configure do |config|
  config.passwords_enabled = true
  # config.passwords_enabled = false # Use only other explicitly enabled methods.

  # Browser sessions: bin/rails generate add_auth:session_upgrade
  config.session.enabled = false
  config.session.lifetime = 43_200 # 12 hours, absolute expiry.
  config.session.idle_timeout = 1800 # 30 minutes; no greater than lifetime.

  # Other feature settings follow in the generated file.
end

This excerpt illustrates the format; keep the complete generated file. To choose an alternative, edit the existing assignment rather than adding a second active value. Run the matching generator and migrations before enabling a feature. Generators activate their own default enablement setting while preserving custom expressions; review the result and resolve any remaining disabled setting deliberately.

The file covers sessions, account lifecycle, email links, reauthentication, passkeys and recovery, notices, mail and counters, maintenance, captcha, providers, native sessions, presentation and cryptographic adapters. Rails supplies its digest secret automatically; retain that configuration. Use the feature-enablement guide and settings reference for required values and verification. Integration-specific initializers still explain provider middleware, captcha credentials and mobile clients.

Update an existing initializer

add_auth:install never overwrites an existing file, including when upgrading from 0.3.0. After the target package is published, follow the upgrade procedure, then inspect the version and template in the installed bundle:

bundle exec ruby -e 'require "add_auth"; puts AddAuth::VERSION'
cat "$(bundle show add_auth)/lib/generators/add_auth/install/templates/initializer.rb"

Confirm the version is 0.4.0 before using this page’s new options. Compare the template with your existing initializer and merge the comments and settings you need. Keep existing feature flags, host callbacks, keys, timeouts and generated authentication requires. Copying all default assignments over a configured app can disable features or replace host policy.

Install account features without email-link sign-in

After 0.4.0 is installed, use this command for password signup, account proofs and password reauthentication without adding email-link sign-in:

bin/rails generate add_auth:accounts --no-email-link
bin/rails db:migrate

Review generated migrations before applying them. The command installs account persistence, notifications and reauthentication, including the storage needed for account mail. It leaves lifecycle disabled until you set config.lifecycle.enabled = true. Account confirmation and reset delivery remain available without email-link sign-in.

For reauthentication alone, use bin/rails generate add_auth:step_up --no-email-link. Both generators enable email links by default when this option is omitted. The option preserves an already-enabled email-link feature; it does not switch an existing app to password-only. Passkey generation also enables email-link prerequisites, so review your final configuration after every feature addition.

Allow password signup before email confirmation

The default remains required confirmation. To let otherwise eligible password users register and sign in immediately, first run the 0.4.0 accounts generator, apply its additive add_auth_provisioned_at migration and review host onboarding callbacks. Edit these values in the existing configuration block:

config.lifecycle.enabled = true
config.lifecycle.confirmation_required = false
config.lifecycle.reset_unconfirmed = false

Successful password signup creates the account, performs local provisioning and creates one finite session in the same database transaction. The user signs in without waiting for a confirmation email; confirmed_at stays nil. Provisioning failure rolls back the signup. Duplicate or retried registration does not sign into an existing account or provision it again. Later email confirmation does not repeat completed provisioning.

Signup itself does not depend on SMTP. Configure delivery for later confirmation, reset, address-change and security emails. General and lifecycle eligibility callbacks still apply: a host callback that requires confirmation will continue to deny an unconfirmed user. Disabled, deleted, locked and strict-account restrictions also remain in force. Provider-only enrollment still requires independent confirmation.

Choose unconfirmed password-reset behavior

By default, an unconfirmed user must confirm the address before password reset or use your support process. In an optional-confirmation host, you may separately opt into:

config.lifecycle.reset_unconfirmed = true

This permits the holder of the account’s current stored mailbox to replace its password after consuming an exact-address, single-use reset proof. Merely entering an email address does not authorize reset. Consuming the proof revokes prior authority but does not sign the user in, confirm the address or run provisioning.

This option requires confirmation_required = false. It does not enable unconfirmed unlock mail, provider-only password enrollment or trusted passkey recovery. Address changes still need fresh reauthentication and proof of the new address. An unconfirmed address is not trusted recovery evidence.

Verify the selected behavior

Restart the host after editing initializers, then run:

bin/rails add_auth:doctor

1. For required confirmation, verify signup waits for delivered confirmation and confirmation does not itself sign in. For optional confirmation, visit /account/sign-up and verify immediate password sign-in with confirmed_at still unset.
2. Retry a signup and simulate a local provisioning failure with synthetic accounts. Verify no duplicate onboarding or unintended session survives.
3. Exercise your chosen reset policy, including expired and already-used proofs. Verify reset alone never confirms or signs in the account.
4. Check /sign-in offers only intended methods. Exercise registration and account changes with Turbo, JavaScript without Turbo and permitted no-JavaScript navigation.

If the initializer is still short, compare the installed package version and remember that install preserves existing files. If doctor reports missing provisioning schema, rerun the accounts generator and apply its reviewed additive migration. If an optional-confirmation user remains denied, inspect both eligibility callbacks and the actual lock/disabled/strict policy; do not fabricate confirmation timestamps.

Next, use the deployment checklist for host services and the configuration reference for other features.