Allow integration tests to use supplied passwords for email-backed users #1756

Problem

The user-creation flow is designed for the UI onboarding experience. When a user is created with an email address, the supplied password is intentionally ignored so the user can complete the email confirmation/account activation flow.

The browserless integration tests also create users through POST /api/users, but they need to log in immediately with the password supplied in the test data. They cannot reliably complete the UI/email activation flow.

This currently causes integration tests such as user login, token, change-password, and related scenarios to create users without a usable password.

Proposed change

Add a configuration option controlling whether the supplied password may be used for email-backed users.

Suggested option:

{
  "ServiceOptions": {
    "UserOptions": {
      "UseProvidedPasswordForEmailUsers": false
    }
  }
}

Enable it only in the IntegrationTest configuration:

{
  "ServiceOptions": {
    "UserOptions": {
      "UseProvidedPasswordForEmailUsers": true
    }
  }
}

The option must only take effect when the host environment is IntegrationTest, regardless of configuration values supplied elsewhere.

Expected behavior

• Normal UI/production behavior remains unchanged:
  • email-backed users do not receive an initial password;
  • the supplied password is not persisted or included in email content;
  • the normal confirmation/activation flow remains responsible for setting the password.
• In the IntegrationTest environment, when the option is enabled:
  • an email-backed test user uses the supplied password;
  • the test user can authenticate immediately without browser/UI interaction;
  • existing role and claim assignment behavior remains unchanged.

Implementation notes

• Add the option to the existing user/service options model and bind it through the existing configuration setup.
• Update UserRequestHandler.Handle(CreateUserCommand) so password hashing occurs for email-backed users only when both conditions are true:
  • the environment is IntegrationTest;
  • UseProvidedPasswordForEmailUsers is enabled.
• Keep the default value false.
• Ensure the option cannot accidentally enable this behavior in Development, staging, or production.

Tests

Add or update coverage for:

1. Email-backed user creation in the default/normal mode ignores the supplied password.
2. Email-backed user creation in IntegrationTest mode with the option enabled stores a usable password.
3. The option has no effect outside the IntegrationTest environment.
4. Existing browserless integration scenarios can create a user and authenticate immediately using the supplied password.
5. The supplied password is never included in confirmation or activation email content.