簡體   English   中英

帶有 SES 驗證域身份的 Cognito 用戶注冊后錯誤頁面故障排除

[英]Cognito w/ SES Verified Domain Identity Post User Sign Up Error Page Troubleshooting

一段時間以來,我一直在嘗試解決這個問題,但沒有運氣。

我為我的站點創建了一個 AWS Cognito 用戶池。 對於我的用戶,我使用 email 地址作為用戶名。 我正在使用托管 UI 進行用戶注冊、登錄等操作。我已將用戶池配置為使用經過驗證的 SES 驗證域身份,以及一個由no-reply@myverifieddomainidentity email 地址作為發件人。 域標識仍在 email 沙箱中。 此外,我還有一個額外的 SES Verified Email Identity,我正在使用它來測試 Cognito email 集成。 這個 email 是我個人的 Gmail 地址,不是驗證域身份中的地址。 Cognito 和 SES 資源都是在 us-west-2 中創建的。

我正在嘗試測試新用戶的注冊過程。 在我的應用程序中,用戶單擊“登錄”按鈕,這會將他們帶到登錄頁面的 Cognito 托管 UI。 我可以單擊“注冊”按鈕並看到“注冊”表單。 我使用我的個人地址 email 填寫信息,然后單擊“注冊”按鈕。 然后我被重定向到/error頁面。

在我的 Cognito 用戶池中,我看到用戶已添加,但我從未收到確認 email。查看 SES 儀表板,它從不報告已發送任何電子郵件。 這告訴我問題出在 Cognito 和 SES 之間。 我找不到任何記錄 Cognito 或 SES 的方法來確定為什么電子郵件沒有發出或為什么我被重定向到 Cognito 托管 UI 的/error頁面。 CloudTrail 僅顯示所獲取頁面的 Cognito 事件,不顯示我能找到的任何故障。

我已經按照 AWS 文檔 ( https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-email.html#user-pool-email-configure ) 中的描述為 Congito 設置了我的 SES 驗證域. 在第 3 步中,它表示我不需要向 Cognito 授予任何額外權限(請參閱“授予使用您的 Amazon SES 配置的權限”)。 但是,我嘗試按照標題為“授予使用默認 email 功能的權限”的步驟 3 中的概述向我的 SES 驗證域添加授權策略,但這也沒有用。

我什至通過 AWS CLI 執行了注冊過程並成功返回,但沒有發送 email。

我已經從 SES 成功發送了模擬測試電子郵件,沒有任何問題。

我已經閱讀了我能找到的任何 AWS 文檔、博客和 SO 帖子來幫助解決這個問題。 不幸的是,我無法通過亞馬遜創建支持票,因為這是我的個人項目,不為該級別的服務付費。

我認為我不需要為已驗證的域設置任何 MX 記錄,因為我還沒有計划接收任何電子郵件,只是發送。 我也不應該像文檔中概述的那樣為no-reply@myverifieddomainidentity創建額外的 SES Verified Email 地址,但我已經嘗試過了。 我也不認為我需要離開 SES 沙箱才能工作,只要我向已驗證的 Email 身份發送電子郵件,但我在這里可能是錯的。

我正在尋求幫助來解決這個問題。 如果有一種方法能夠監控 Cognito 和/或 SES 以明確確定兩者無法協同工作的原因,那就太好了。 除了將 CloudTrail 事件發送到 CloudWatch 之外,我沒有看到 Cognito 的任何日志記錄選項,這似乎沒有幫助。 對於 SES,我似乎可以添加主題以用於監控退回的電子郵件等,但這在這種情況下對我沒有幫助,因為電子郵件似乎甚至沒有到達 Cognito。 我似乎無法找出托管 UI 將我重定向到/error頁面的原因。

資源是使用 Terraform 創建的。張貼在這里以便您可以看到完整的配置。

resource "aws_ses_domain_identity" "this" {
  domain = aws_route53_zone.external.name
}

resource "aws_route53_record" "ses_domain_identity_verification_record" {
  zone_id = aws_route53_zone.external.zone_id
  name    = "_ses_domain_identity_verification" # TODO: need full domain name? "_ses_verification_record.${aws_route53_zone.external.name}"
  type    = "CNAME"
  ttl     = "60"
  records = [aws_ses_domain_identity.this.verification_token]
}

resource "aws_ses_domain_dkim" "this" {
  domain = aws_ses_domain_identity.this.domain
}

resource "aws_route53_record" "ses_dkim_verification_record" {
  count = 3 # resource aws_ses_domain_dkim creates 3 tokens

  zone_id = aws_route53_zone.external.id
  name    = "${element(aws_ses_domain_dkim.this.dkim_tokens, count.index)}._domainkey"
  type    = "CNAME"
  ttl     = "1800"
  records = ["${element(aws_ses_domain_dkim.this.dkim_tokens, count.index)}.dkim.amazonses.com"]
}

resource "aws_cognito_user_pool" "this" {
  name = local.project-deployment-name

  admin_create_user_config {
    allow_admin_create_user_only = false
  }

  password_policy {
    minimum_length                   = 8
    require_lowercase                = true
    require_numbers                  = true
    require_symbols                  = true
    require_uppercase                = true
    temporary_password_validity_days = 1
  }

  username_attributes = ["email"]

  # TODO: see https://github.com/hashicorp/terraform-provider-aws/issues/26726
  #  user_attribute_update_settings {
  #    attributes_require_verification_before_update = ["email"]
  #  }

  email_configuration {
    email_sending_account = "DEVELOPER"
    from_email_address    = "no-reply@${aws_ses_domain_identity.this.domain}"
    source_arn            = aws_ses_domain_identity.this.arn
  }

  account_recovery_setting {
    recovery_mechanism {
      name     = "verified_email"
      priority = 1
    }
  }
  
  schema {
    name                = "email"
    attribute_data_type = "String"
    required            = true
    mutable             = true
  }

  schema {
    name                = "name"
    attribute_data_type = "String"
    required            = true
    mutable             = true
  }

  schema {
    name                = "birthdate"
    attribute_data_type = "String"
    required            = true
    mutable             = true
  }
}

任何幫助表示贊賞。 謝謝你。

編輯:

我剛剛嘗試將 Cognito 與默認 email 解決方案一起使用,使用no-reply@verificationemail.com的默認 email 地址,我剛剛遇到了相同的行為,因此問題可能不在 Cognito 和 SES 之間,而是在 Cognito 本身。 托管 UI 重定向到錯誤頁面,用戶已添加到用戶池,但未收到 email。

更正答案:

我意識到我的問題實際上是沒有為auto_verified_attributes設置值。 我沒有正確理解該設置的目的。 將以下配置添加到我上面的aws_cognito_user_pool資源中,解決了我的特定問題。

auto_verified_attributes = ["email"] 

上一個答案:

所以事實證明,這個問題就在我面前,但一點都不明顯。

  # TODO: see https://github.com/hashicorp/terraform-provider-aws/issues/26726
  #  user_attribute_update_settings {
  #    attributes_require_verification_before_update = ["email"]
  #  }

沒有啟用“屬性驗證和用戶帳戶確認”功能會完全破壞注冊過程。 我什至不認為這是原因,因為 1) 這是一項新功能,我懷疑在此功能之前的注冊過程會起作用,並且 2) 它是一項可選功能。

我從來沒有找到任何好的方法來確定為什么用戶在注冊過程中被重定向到錯誤頁面。 我懷疑唯一真正找出答案的方法是向 AWS 提交票證。 我只是通過拼命調整配置直到工作正常才發現這一點。

希望這會幫助發現自己處於類似情況的其他人。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM