別のID基盤から、パスワード、確認済みメール、ソーシャル連携ごとユーザーをインポートし、再登録を不要にします。まずテスト実行、次にインポートです。
本番アプリケーションで認証 → ユーザーをインポートを開き、新しいインポートを押して、CSVまたはJSONファイルを1つアップロードし、テスト実行を行ってからインポートを開始を押します。ユーザーは、パスワード、確認済みメール、ソーシャル連携、認証アプリ、そしてあなたのユーザーIDをそのまま保持でき、アプリがDiditでサインインさせるまで、ユーザーには何も変わりません。
Auth0、Clerk、Firebaseなどの別のID基盤、自社のデータベース、またはCSVやJSONのエクスポートから、ユーザーを移行できます。ユーザーをインポートページは本番アプリケーションにのみ表示され、タイトルは移行です。
#インポートで保持できるもの
| 保持されるもの | 備考 |
|---|---|
| パスワードハッシュ | パスワードハッシュをインポートをオンにします。オンにしない場合は、新しいパスワードが必要を選びます。 |
| 確認済みメール | 確認済みメールアドレスを保持：メールを再度確認する必要はありません。 |
| ソーシャルサインインの連携 | ソーシャルログインの連携を保持：対応するプロバイダーのアカウントは連携されたままです。 |
| 認証アプリ | 認証アプリを保持。 |
| あなたのユーザーID | ユーザー ID を保持：データベースとこれらのユーザーを結び付けるIDです。 |
| 組織のロール | ユーザーは、組織での自分のロールを保持します。 |
パスキーはインポートできません。パスキーは作成されたドメイン、つまり以前のドメインに属するため、ユーザーはサインイン後に新しいパスキーを追加します。
ユーザーのパスワード形式を保持できない場合、そのユーザーは新しいパスワードを設定します。対応する形式の一覧は、移行のドキュメントにあります。
#ファイルの上限
1回のインポートは、CSVまたはJSONファイル1つで、最大25 MB、100,000人までです。ユーザーは1,000人ずつのバッチでインポートされ、中断されたインポートは、止まったところから再開します。
アップロードしたファイルは暗号化されて保存されます。インポートが終了したとき、テスト実行が失敗したとき、またはインポートされなかったテスト実行から24時間後に削除されます。
#ユーザーをインポートする
- ユーザーをインポートを開く
本番アプリケーションで認証を開き、ユーザーをインポートを選びます。認証の設定を変更できるロールが必要です。
- 新しいインポートを押す
ユーザーが現在どこにいるかを選びます。別のID基盤、自社のデータベース、CSVまたはJSONのエクスポートです。そしてファイルをアップロードします。
- 保持するものを選ぶ
上で説明した、パスワード、ソーシャル連携、確認済みメール、認証アプリ、ユーザーIDのスイッチを設定します。
- テスト実行を行う
アップロードは必ずテスト実行から始まります。テスト実行はすべてのユーザーを確認するだけで何も書き込まず、パスワードを保持できる人数、リセットが必要な人数、スキップされる人数を表示します。失敗した場合はエラーが一覧表示されるので、ファイルを修正して再度アップロードしてください。
- インポートを開始を押す
確定するとユーザーが作成されます。インポート履歴に、すべてのインポートが一覧表示されます。インポートを再実行しても、すでに登録済みのユーザーはスキップされます。
ユーザーがDiditを使うあなたのアプリで自分で作成した既存のアカウントは、インポートによって変更されることはありません。
#切り替えるまで何も変わりません
インポートは、Diditにユーザーを作成するだけです。アプリがDiditでユーザーをサインインさせ始めるまで、ユーザーは何も気付きません。それまでは、現在の基盤が引き続き動作します。
#切り替えの手順
- ユーザーをインポートします。
- パスワードのアカウントとソーシャルサインインのアカウントを含め、いくつかのアカウントでテストします。
- アプリのサインインをDiditに向けます。アプリにサインインを追加するをご覧ください。
- データベースが変わらないように、ユーザーIDを保持します。
AIコーディングエージェントにエクスポートファイルを書かせたい場合は、ページのAI コーディングエージェントで移行も利用できます。
#関連記事
まだ解決しませんか？担当者に相談する。
組織 ID と、問い合わせたいセッション ID を添えてください。