auth0ストラテジーを使うこともできます。
changePasswordアクションスクリプトが呼び出されます。
自動移行
サイズ
requireステートメントの一部として参照された可能性のあるnpmモジュールは含まれません。
カスタムデータベース接続の構造に関するベストプラクティス
カスタムデータベース接続の構造に関するベストプラクティスについて説明します。
カスタムデータベース接続は通常、独自のレガシーIDストアにアクセスして認証（レガシー認証 と呼ばれることがあります）や自動移行によるユーザーのインポート（** トリクルダウン移行** または レイジー移行 と呼ばれます）を行うために使用されます。カスタムデータベース接続は、Auth0のマルチテナントアーキテクチャを使用するシナリオで、Auth0テナントへのプロキシアクセスにも使うことができます。詳細については、「複数テナントのアプリケーションに関するベストプラクティス」をお読みください。
カスタムデータベース接続の作成や構成には通常、が使用されます。データベース接続を作成してから、［Use my own database（独自のデータベースを使用する）］ を有効にして、データベースのアクションスクリプトを編集できるようにします。カスタムデータベース接続の作成や構成には、Auth0 の接続作成エンドポイントと
自動移行では、Auth0は新しいユーザーをAuth0管理のIDストア（データベース）内に作成します。Auth0がユーザーを認証する際には、Auth0管理のIDストアにあるIDが使用されます。これを行うために、Auth0は、レガシーIDストアに対照してユーザーが認証されることを要求します。この認証に成功した場合にのみ、Auth0はAuth0管理のデータベース内に新しいユーザーを作成します。新しいユーザーの作成には、認証中に提供されたのと同じIDとパスワードが使用されます。
自動移行のシナリオでは、ユーザーの作成は通常、ログインアクションスクリプトが完了した後で実行されます。ユーザーをレガシーIDストアから削除する際には、ログインスクリプト内でインライン操作として行うのではなく、独立処理として行うことをお勧めします。そうすることで、ユーザーを誤って削除したために、移行でエラー条件が発生することを防ぎます。
自動移行では、ユーザーは引き続きレガシーIDストアで管理され、必要に応じて削除やアーカイブを行うことができます。これに関する弊害は、ユーザーがAuth0から削除されても、レガシーデータストアに存在したままになることです。このときに、削除されたユーザーがログインしようとすると、ログインまたはユーザー取得スクリプトが実行され、そのユーザーがレガシーIDストアから再度移行されます。
ログインまたはユーザー取得スクリプトが完了する前か、レガシーストアが最終的に削除される前に、レガシーストアのユーザーIDに移行済のマークを付けて、意図的に削除したユーザーが思いがけず作成し直されてしまうことを防ぐようにお勧めします。
アクションスクリプトの実装では、総サイズが100 KBを上回らないことをお勧めします。Auth0プラットフォームでパッケージングと転送が処理されるため、サイズが大きいほど遅延が長くなります。そして、これはシステムの性能にも影響を与えます。100 KBの制限には、