Email-code signup asks for a username before the account exists

Does every request that creates an email-code account still pass CAPTCHA?

The patch used to demand a token on the request that submitted the code. It now demands one only when the request carries a username, is not an approval signup, and has no user fields or full name missing. Those negations mirror the controller's early returns, so the requests it lets through stop at required_username_provided before the code is consumed. Approval signups are checked on the completion request instead. Decide whether that mirroring holds for every way a request reaches EmailLoginCode::Redeem.

• The new predicate the username condition, and the existing-user and invite exits above it
  ▸ plugins/discourse-captcha/lib/discourse_captcha/session_controller_patch.rb:39-46 Changed

         return false if matched_user.present? || params[:invite_key].present?
         return false if !registration_via_login_code_open?
   
  -      pending_approval_signup?(matched_user) ||
  -        (!signup_user_fields_missing? && !signup_full_name_missing?)
  +      !pending_approval_signup?(matched_user) && params[:username].present? &&
  +        !signup_user_fields_missing? && !signup_full_name_missing?
       end
   
       include CaptchaVerification
  

• The exits it mirrors approval signups, then missing fields or name, both returning before Redeem
  ▸ app/controllers/session_controller.rb:966-976 At head

      return process_verified_invite_login_code(matched_user) if params[:invite_key].present?
  
      return begin_verified_login_code_signup if pending_approval_signup?(matched_user)
  
      if matched_user.nil? && registration_via_login_code_open?
        user_fields_required = signup_user_fields_missing?
        name_required = signup_full_name_missing?
        if user_fields_required || name_required
          return render json: { user_fields_required:, name_required: }
        end
      end
  

• Approval completion check runs CAPTCHA when the stored proof was not verified, which is now every approval signup
  ▸ plugins/discourse-captcha/lib/discourse_captcha/session_controller_patch.rb:17-25 At head

      def complete_verified_login_code_signup
        proof = verified_login_code_signup_proof_for(params[:signup_token].to_s)
        if proof.is_a?(Hash) && !proof[:captcha_verified] && (error = captcha_verification_error)
          render json: { error: I18n.t(error) }
          return
        end
  
        super
      end
  

• What the request specs pin no CAPTCHA on the code-only request, no account without one, and the generated-name case plugins/discourse-captcha/spec/requests/discourse_captcha/session_controller_spec.rb:16-75

When a chosen username is rejected, is the code still good for another try?

Every new account now arrives with a member-chosen name, so rejection is the ordinary path. On the login-code path the reserved-name policy runs before the transaction, and a format or uniqueness failure fails the model step inside it, which leaves the code unconsumed inferred from tests. On the invite path InviteRedeemer now takes a verified-email username as given instead of falling back to a suggestion, so the User validator at app/models/user.rb:2156-2181 is its only format and uniqueness check, and the resulting RecordInvalid comes back as username_errors from unchanged code. Judge whether both paths leave the code and any staged account reusable.

• Policies, then the transaction username_allowed runs before consume_code and account creation
  ▸ app/services/email_login_code/redeem.rb:46-56 At head

    policy :username_allowed
    policy :required_fields_provided
    policy :required_full_name_provided
    policy :required_username_provided
  
    lock(:email) do
      transaction do
        step :consume_code
        model :user, :ensure_user
      end
    end
  

• Invite username taken as given the format and availability branch is skipped once the email is verified
  ▸ app/models/invite_redeemer.rb:99-108 Changed

     )
       raise Discourse::SiteArchived if SiteSetting.site_archived
   
  -    if username && UsernameValidator.new(username).valid_format? &&
  -         User.username_available?(username, email)
  +    if email_verified && username.present?
  +      available_username = username
  +    elsif username && UsernameValidator.new(username).valid_format? &&
  +          User.username_available?(username, email)
         available_username = username
       elsif email_verified
         available_username =
  

• The validator that now decides format and uniqueness always; reserved names only with enforce_username_restrictions, which the invite path never sets, so the invite service's own policy covers them from unchanged code
  ▸ app/models/user.rb:2156-2174 Unchanged

    def username_validator
      username_format_validator ||
        begin
          if will_save_change_to_username?
            if enforce_username_restrictions &&
                 (
                   User.reserved_username?(username) ||
                     UsernameValidator.clashing_with_existing_route?(username)
                 )
              errors.add(:username, I18n.t("login.reserved_username"))
            end
  
            existing =
              DB.query(USERNAME_EXISTS_SQL, username: self.class.normalize_username(username))
  
            user_id = existing.select { |u| u.is_user }.first&.id
            same_user = user_id && user_id == id
  
            errors.add(:username, I18n.t(:"user.username.unique")) if existing.present? && !same_user
  

• Rejection specs on the invite service missing, reserved, route-clashing, invalid and taken names each assert the code unconsumed; the login-code service carries the same contexts at spec/services/email_login_code/redeem_spec.rb:220-290 spec/services/invite/redeem_with_email_code_spec.rb:171-250

What should the server-side generated-username flag change?

The controller sets generated_username only when a proof in the server session matches the code, the email, the name and the signup context, and Redeem forwards it to CreateFromVerifiedEmail, whose call never reads it. Its whole server-side effect is in the controller: a rejected generated name is replaced with a fresh one instead of returning an error. The mode is only on when a plugin registers email_login_code_username_mode; otherwise lib/discourse_plugin_registry.rb:306-310 returns the default, and no plugin in this repository registers it from unchanged code. The same is true one layer up: the contract still declares username_required at app/services/email_login_code/redeem.rb:11 and the approval completion still sends it at app/controllers/session_controller.rb:1095, but no policy reads it any more. Decide whether each unused input is leftover plumbing or a missing behaviour.

• The option nothing reads declared beside username; restrictions are still decided by username.present? app/services/user/action/create_from_verified_email.rb:3-39
• Where Redeem forwards it true only when the proof's code id matches the code being redeemed
  ▸ app/services/email_login_code/redeem.rb:146-158 At head

    def ensure_user(existing_user:, login_code:, params:, ip_address:, options:)
      generated_username =
        options.generated_username && options.generated_username_login_code_id == login_code.id
      existing_user ||
        User::Action::CreateFromVerifiedEmail.call(
          email: params.email,
          ip_address: ip_address,
          user_fields: params.user_fields,
          name: params.name,
          password: params.password,
          username: params.username,
          generated_username: generated_username,
        )
  

• The mode switch defaults to :required unless a plugin modifier answers otherwise
  ▸ app/controllers/session_controller.rb:1347-1356 At head

    def email_login_code_username_mode(email, signup_context)
      DiscoursePluginRegistry.apply_modifier(
        :email_login_code_username_mode,
        :required,
        email,
        server_session,
        signup_context,
        cookies[:destination_url],
      )
    end
  

• A retry instead of an error a rejected generated name re-renders the details step with a new one app/controllers/session_controller.rb:1004-1014

Open question Is generated_username on CreateFromVerifiedEmail meant to relax a check, and should the unread username_required go?

Is it acceptable that a chosen avatar can be lost without a word?

The avatar is picked before the account exists and saved by the browser after account_created: an upload then pickAvatar, or selectAvatar for a preset, with every failure swallowed before the redirect. The picker offers upload when can_upload_avatar is true, which only checks groups, but the upload endpoint also refuses avatars when auth_overrides_avatar or discourse_connect_overrides_avatar is set (app/controllers/uploads_controller.rb:51-56) from unchanged code. On such a site a member can choose a file, see it previewed, and arrive with the default avatar. Approval signups never reach this save, because app/controllers/session_controller.rb:1180-1181 answers pending_approval first.

• The deferred save upload or select as the new user, then an empty catch
  ▸ frontend/discourse/app/components/code-login-form.gjs:1018-1040 At head

        await updateCsrfToken();
        if (selection.file && result.can_upload_avatar) {
          const data = new FormData();
          data.append("type", "avatar");
          data.append("user_id", user.id);
          data.append("files[]", selection.file);
          const upload = await ajax("/uploads.json", {
            type: "POST",
            data,
            processData: false,
            contentType: false,
            timeout: 30000,
            ignoreUnsent: false,
          });
          if (upload?.id) {
            await user.pickAvatar(upload.id, "custom");
          }
        } else if (selection.url) {
          await user.selectAvatar(selection.url);
        }
      } catch {
        // Avatar customization must not block an account that was successfully created.
      }
  

• The upload endpoint's refusal the two override settings and the group check, returning 422 for an avatar upload from unchanged code
  ▸ app/controllers/uploads_controller.rb:51-56 Unchanged

      if type == "avatar" &&
           (
             SiteSetting.discourse_connect_overrides_avatar || SiteSetting.auth_overrides_avatar ||
               !me.in_any_groups?(SiteSetting.uploaded_avatars_allowed_groups_map)
           )
        return render json: failed_json, status: :unprocessable_entity
  

• What the picker is told can_upload_avatar from the default trust-level groups and any invite groups app/controllers/session_controller.rb:1318-1333

Open question Should the override settings hide the upload option, or should a failed save tell the member?

Should sites that never set enable_random_usernames lose random names?

The setting arrived on 2026-08-27 defaulting to on, and this flips the default. Every site still on the default stops getting adjective-and-noun suggestions on the username and approval details steps, loses the regenerate button (frontend/discourse/app/components/code-login-form.gjs:1282), and gets a 404 from the random-username endpoint. The plugin-driven generated mode ignores the setting through allow_when_disabled: true. Whether a release shipped with the old default is uncertain; the release tags would settle it.

• The default true to false, still dependent on code logins
  ▸ config/site_settings.yml:696-702 Changed

           - everyone
     enable_random_usernames:
       client: true
  -    default: true
  +    default: false
       area: "login"
       depends_on:
         - enable_local_logins_via_code
  

• The endpoint guard ensure_random_username_access raises NotFound when the setting is off
  ▸ app/controllers/users_controller.rb:2193-2197 At head

  
    def ensure_random_username_access
      raise Discourse::NotFound if !SiteSetting.enable_random_usernames
      return redirect_to_login_if_required if current_user
      return if !SiteSetting.login_required?
  

• The bypass generated names call the generator whatever the setting says app/controllers/session_controller.rb:1358-1370

Does the new for_user_id guard turn away a caller that still needs it?

check_username used to load any for_user_id for any caller, anonymous included, and check availability against that user's email. It now raises for an anonymous caller and requires ensure_can_edit_username!; the signup form stopped sending the id. The username preference, which does send it, only shows its edit control when the serialized can_edit_username is true, computed by the same guardian method at app/serializers/user_serializer.rb:216-218 from unchanged code. Decide whether any caller outside this repository relied on the old behaviour.

• The guard anonymous callers refused, then the edit permission enforced
  ▸ app/controllers/users_controller.rb:714-721 At head

    def user_from_params_or_current_user
      return current_user if !params[:for_user_id]
      raise Discourse::InvalidAccess if !current_user
  
      user = User.find(params[:for_user_id])
      guardian.ensure_can_edit_username!(user)
      user
    end
  

• The guardian rule overrides, staff, the change period, then self within it from unchanged code
  ▸ lib/guardian/user_guardian.rb:24-30 Unchanged

    def can_edit_username?(user)
      return false if SiteSetting.auth_overrides_username?
      return true if is_staff?
      return false if SiteSetting.username_change_period <= 0
      return false if is_anonymous?
      is_me?(user) && user.created_at > SiteSetting.username_change_period.days.ago
    end
  

• Where the preference gets its flag the same guardian call, so its edit control and the guard agree from unchanged code
  ▸ app/serializers/user_serializer.rb:216-218 Unchanged

    def can_edit_username
      scope.can_edit_username?(object)
    end