web-dev-qa-db-ja.com

AWS Cognitoワークフロー:プライマリユーザー名にメールエイリアスを使用する

それで、AWS Cognitoの周りに頭を向けようとしていますが、いくつかの壁にぶつかっています。

だから今、私はアカウントを登録し、それを確認してサインインすることができます。とても簡単です。エッジケースは私の壁があるところです。

これが私がこれまでに得た情報です:

  • usernameは一度作成すると変更できません
  • username値としてUUIDを使用しています
  • emailaliasとしてマークされています。これは、Cognitoの用語では、usernameに加えて、サインインに使用できることを意味します。
  • emailaliasとして選択されている場合、ドキュメントごとに、同じ値をユーザー名として使用することはできません( http://docs.aws .Amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases ):

    メールがエイリアスとして選択されている場合、ユーザー名は有効なメール形式と一致できません。同様に、電話番号がエイリアスとして選択されている場合、有効な電話番号パターンに一致するユーザー名は、そのユーザープールのサービスでは受け入れられません。

  • emailアドレスは[〜#〜] only [〜#〜]を使用して、アカウントが確認されたらサインインできますhttp://docs.aws.Amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-aliases

    電話番号とメールアドレスは、電話番号とメールアドレスが確認された後にのみ、ユーザーのアクティブなエイリアスになります。したがって、メールアドレスと電話番号をエイリアスとして使用する場合は、それらの自動検証を選択することをお勧めします。

ここに私のエッジケースがあります。

ユーザーがサインアップしたが[〜#〜]しない[〜#〜]場合は、すぐに確認します。

  • 彼らは呼ばれる
  • アプリがクラッシュするかもしれません
  • 接続を失う
  • 彼らのバッテリーが死ぬ
  • 彼らは強制終了します
  • アプリが誤って削除されます。

彼らの心の中で彼らは単に自分のアカウントを検証せずにサインアップしました。この時点では、登録したと思われるアカウントを検証する方法は事実上ありません。メッセージングで解決できると思います:

「メールアドレスを確認するまで、アカウントは作成されません。」またはそれらの線に沿って何か。とにかく...

  • usernameとしてランダムに割り当てられたUUIDを知らないため、サインインを試みることはできません。
  • そうでない場合でも、ユーザー名としてメールアドレスを提供しました。ユーザーは自分の電子メールアドレスを入力しただけなので、ユーザーのPOVからusernameが何であるかさえわからなくなります。
  • 彼らが期待できる最善の方法は、もう一度サインアップすることです。 (上記の確認警告を読んだと仮定して)この場合、Cognitoは未確認のアカウントの蓄積を中止した可能性があります。

「積み上げる」という表現は強すぎるかもしれませんが、これはかなりフリンジケースのようです。

プラスの面は、彼らがemailを「確認」していないため、emailは一意に制約されないため、同じemailアドレスで再度サインアップできます。 verifiedです。既に確認済みのアドレスを確認しようとすると、AliasExistsExceptionを受け取ります。これは実際に私がテストしたばかりの興味深いポイントをもたらします。

メールアドレスで登録し、そのメールアドレスを確認することでアカウントが確認されます。次に、正しい方向を向いてsameメールアドレスでサインアップできます。重複したメールアドレスでそのアカウントを確認しようとするまで、公式のAWSエラーは表示されません。以前にこのエラーを表示する方法はありませんか? Pre-Signup Triggerで検証サービスを作成するのは開発者の責任であると期待しています。

このトリガーは、ユーザーが情報を送信してサインアップするときに呼び出され、カスタム検証を実行して、サインアップ要求を受け入れるか拒否することができます。

要約すると、質問を言い換えると:

実際には、必須のようですが、Cognitoで電子メールアドレスを使用する場合、電子メールのアカウントが存在しないことを確認するために、事前登録ラムダが必要です。 AWS例外は、検証が試行されるまで処理されません。

ここでの私の仮定は正しいですか?ここでrequiredここでは、できるだけ早くメールアドレスが利用できないことをユーザーに通知することはかなり合理的だと思います。例えば:

John Doe : [email protected]
Jane Doe : [email protected]
17
Adam Venturella

あなたは正しいです。別の解決策は、ラムダ(preSignUpによってトリガーされない)を作成し、ユーザーが電子メールフィールドへの入力を終了するたびに呼び出されるようにすることです。また、サインアップイベントを送信する前に、「このメールはすでに使用されています」または「このメールは利用可能です」という応答を受け取ります。

質問の最初の部分を参照します。ユーザーがメールをすぐに確認しない場合。おそらくコードによる確認を意味します。この問題を回避するために、電子メールに送信されるリンクによる確認を使用することを好みます。

1
jWang1