在通过电话确认之前 Cognito 更改 phone_number答案

【问题标题】：Cognito change phone_number before confirm via Phone在通过电话确认之前 Cognito 更改 phone_number
【发布时间】：2019-12-05 23:36:14
【问题描述】：

我想在用户通过电话确认之前更改用户的phone_number 属性。我的流程步骤：

用户通过用户名、密码和电话号码注册
用户必须输入手机收到的确认码。在此步骤中用户想要更改电话号码（号码错误或更改电话...）

2.1 如果第一个电话号码错误，则下一个电话号码正确 -> 只发送了一个确认码 -> 有效！

2.2 如果第一个电话号码和下一个电话号码正确 -> 已发送两个确认码（第一个 - xxx，第二个 - yyy） -> 用户输入第二个确认码，Cognito 会抛出 CodeMismatchException: Invalid verification code provided, please try again. 错误。用户输入第一个代码，用户已被确认，但在 Cognito 系统中，用户有 phone_number 是第二个数字，phone_number_verified 是 true。

我使用adminUpdateUserAttributes 更改具有状态为UNCONFIRMED 的用户的phone_number。在我拨打更改电话号码后自动发送确认码。

如何解决这个问题？

!!!更新

目前，我从我的应用程序中删除了 User can update their phone_number before they confirmed via phone 功能。

大约需要 5 天，我只是想记下我的情况。

当您尝试更新phone_number（或email）属性时，Cognito 会自动向您的手机（或电子邮件）发送确认信息，这是第一个代码 - (1st - xxx)，确认代码您的新属性值（不用于用户确认）。

同时，逻辑代码调用resendConfirmationCode函数，它发送第二个代码-(2nd - yyy)，这是只有第二个代码工作的主要原因（我们使用confirmSignUp函数来处理代码）。

【问题讨论】：

要确认场景，您有 2 个电话号码：电话 1 和电话 2。您使用电话 1 注册并使用 adminUpdateUserAttributes 将电话号码更改为电话 2。您在电话 2 上收到的代码无法确认用户，但您在电话 1 上收到的代码可以，并且确认的电话号码是电话 2？
@behrooziAWS 是的！这正是我的情况。我认为电话2的确认码是属性验证码（不是确认注册码），自动发送的代码会让有人尝试更改电话号码（或电子邮件）。如何暂时禁用该 SMS 功能？

标签： amazon-web-services aws-lambda amazon-cognito

【解决方案1】：

我是 Cognito 团队的一员，和 behrooziAWS 一样。在查看您的方案后，这似乎是我们这边的一个错误。我会在团队中提及它，以便我们相应地优先考虑它。

【讨论】：

谢谢！您可以阅读我在问题中的评论，这不是问题。一切都很好，但我的情况不正常。
这有什么更新吗？或者是否有我们可以关注的 github 问题？
偶然发现完全相同的问题。 4 年了，它仍然存在，在这一点上它是一个功能；）
今天也遇到了这个。有关于这种行为的任何消息吗？

【解决方案2】：

这个问题是不久前提出的，但有些人仍然遇到发送验证码的问题，并且无法验证尚未确认的帐户上的代码，因此我找到了适合我们的解决方案。

我们的身份验证流程是：

SignUp -> OTP Screen -> Confirmed OTP -> Cognito Account confirmed -> Custom email sent to user to verify email address -> Update attribute email_verified = true

在 OTP 屏幕上，我们显示 OTP 已发送到的号码，如果号码不正确，我们允许用户返回注册页面并更改号码并重新提交注册。我们在 cognito 上为用户使用 UUID，以便允许用户再次注册，而不会在帐户已经存在但未确认的情况下导致错误。

这意味着我们在 cognito 中获得了两个具有 UUID 的帐户，一个已确认，一个未确认，帐户的唯一区别是电话号码。然后，我们会在一段时间后删除未经确认的帐户。例如 7 天

【讨论】：

绝对是一种独特的方式来解决这个问题。您如何处理未确认的帐户？
我们可以使用aws sdk处理未确认的账户，获取账户的状态和创建。如果它们在日期阈值内且仍处于未确认状态，请删除该帐户。您可以将 Lambda 与 cloudwatch 事件一起使用，以根据需要随时扫描用户池中的用户，我们只需将其设置为每天检查状态

【解决方案3】：

对于其他寻求此问题的答案的人，我最终做的是编写一个 lambda，它基本上检查用户是否未经确认，删除该用户，然后再次注册。我最初选择了 updateUserAttributes 路线，但万一坏人访问了 lambda 并将已确认用户的电话号码更新为他们的电话号码，我会感到不安全。如果用户使用不同的用户名但从不同的帐户注册相同的号码，它将使其他用户的帐户无效。因此下面的逻辑。

try {
            const userParams = {
                UserPoolId: process.env.userpool_id,
                Username: event.args.username
            };
            const { UserStatus } = await identity.adminGetUser(userParams).promise();
            if (UserStatus === 'UNCONFIRMED') {
                const deletedIdentity = await identity.adminDeleteUser(userParams).promise();
                if (deletedIdentity) {
                    const signupParams = {
                        ClientId: process.env.client_id,
                        Password: event.args.password,
                        Username: event.args.password,
                        UserAttributes: [
                            {
                                Name: 'phone_number',
                                Value: event.args.phoneNumber
                            }
                        ]
                    }
                    const newSignUp = await identity.signUp(signupParams).promise();
                    if (newSignUp) {
                        response.send(event, context, response.SUCCESS, {
                            newSignUp
                        });
                        callback(null, newSignUp)
                    }
                }
            } else {
                response.send(event, context, response.ACCESSDENIED, {
                    error: 'User not authorized to perform this action'
                });
                callback({error: 'User not authorized to perform this action'}, null)
            }

        } catch (error) {
            response.send(event, context, response.FAILURE, {
                error
            });
            callback(error, null)
        }

【讨论】：