![](/img/trans.png)
[英]AWS SES - Generate a unique email address per cognito user for a domain
[英]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.