Skip to content

fix(gen2-migration): preserve email verification disabled setting (#14810)#14847

Draft
dgandhi62 wants to merge 1 commit intodevfrom
fix/gen2-migration-14810
Draft

fix(gen2-migration): preserve email verification disabled setting (#14810)#14847
dgandhi62 wants to merge 1 commit intodevfrom
fix/gen2-migration-14810

Conversation

@dgandhi62
Copy link
Copy Markdown
Contributor

Solves #14810.

Issue Summary

The generate step does not preserve the "Email based user registration/forgot password: Disabled" setting from Gen 1. When autoVerifiedAttributes is ["phone_number"] (not ["email"]), the migration tool incorrectly generates loginWith: { email: true } instead of loginWith: { phone: true }, switching verification from SMS to email.

Reasoning

  1. The issue reports that Gen 1 apps configured with autoVerifiedAttributes: ["phone_number"] get migrated to loginWith: { email: true }, which changes the verification channel from SMS to email.
  2. Read auth.renderer.ts — found the buildLoginWith method which unconditionally emits either email: true or an email options object. It never checks autoVerifiedAttributes to determine whether phone-based verification was configured.
  3. The fix needs to check AutoVerifiedAttributes from the fetched user pool config: if it contains phone_number but not email, the user had email verification disabled and we should emit phone: true instead.
  4. The options.userPool.AutoVerifiedAttributes array is already available in the render options passed to buildLoginWith.

Solution

  • auth.renderer.ts — In buildLoginWith, added a check for isPhoneOnlyVerification (autoVerified includes phone_number but not email). When true, emits loginWith: { phone: true } instead of loginWith: { email: true }. The existing email verification message/subject logic is preserved in the else branch.
  • auth.generator.test.ts — Added a new test case 'generates phone login when email verification is disabled' that mocks a user pool with AutoVerifiedAttributes: ['phone_number'] and UsernameAttributes: ['phone_number'], and asserts the generated resource.ts contains loginWith: { phone: true } with email as a required-but-not-verified user attribute.

Example

Input (Gen 1 — cli-inputs.json):

{
  "cognitoConfig": {
    "autoVerifiedAttributes": ["phone_number"],
    "requiredAttributes": ["email"]
  }
}

Output — before fix (resource.ts):

loginWith: {
  email: true,
},

Output — after fix (resource.ts):

loginWith: {
  phone: true,
},
userAttributes: {
  email: {
    required: true,
    mutable: true,
  },
},

When a Gen1 auth resource had email-based verification disabled
(autoVerifiedAttributes: ["phone_number"] only), the migration
tool incorrectly generated `loginWith: { email: true }` instead
of `loginWith: { phone: true }`.

The fix checks AutoVerifiedAttributes on the user pool: when it
contains only phone_number (not email), the renderer now emits
`phone: true` in the loginWith block, preserving the original
SMS-based verification behavior.

Added a test case that verifies the phone-only verification
scenario with email as a required-but-not-verified attribute.
---
Prompt: Fix issue #14810 — generate step does not preserve
"Email based user registration/forgot password: Disabled"
setting when autoVerifiedAttributes is ["phone_number"].
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant