Skip to main content
アプリが独自の認証システム、ユーザーストア、またはセッションロジックを持っている場合はこのページを使用してください。Clerk Authへの移行は、単なるコードの変更ではなく、データとアイデンティティの移行です。計画がないと、復帰したユーザーが既存のデータへのアクセスを失ったように見えることがあります。
Replit Authを使用していますか? 自動移行フローは対象のReplit Authアプリのみに提供されます。代わりにReplit AuthからClerkへの移行に従ってください。Replitはカスタム認証システムを自動的に移行しません。このページでは、自動インポート手順ではなく、計画と検証のガイダンスを提供します。

アイデンティティの継続性を計画する

  • 今日、あなたの人物とアプリのデータを結びつけている安定した値を特定します。それはユーザーID、メールアドレス、ユーザー名、または別のアカウントレコードかもしれません。
  • 所有権、権限、サブスクリプション、設定、監査記録を含め、その値に依存するすべてのテーブルとサービスを棚卸しします。
  • サインイン動作を変更する前に、新しいアイデンティティシステムが既存のローカルレコードそれぞれをどのように解決するかを決めます。
  • カットオーバー後、まったく新しいユーザーがどのようにローカルレコードへ割り当てられ、紐付けられるかを定義します。
プロバイダーのユーザーID、メールアドレス、または初回サインイン時に作成された新しいアカウントが既存のレコードと一致するとは想定しないでください。カットオーバー前に、代表的なアカウントでマッピングを検証してください。

アカウントの認証情報とセッション

  • パスワードハッシュ、OAuthアイデンティティ、MFAファクター、検証状態、アクティブなセッションを別々に棚卸しします。それぞれ移行のしやすさとセキュリティ要件が異なる場合があります。
  • 実際のアカウントを処理する前に、選択したプロバイダーの最新のドキュメントに照らしてパスワード移行を検証します。認証情報を安全に移行できない場合は、パスワードリセットまたはアカウント連携のフローを計画してください。
  • OAuthアイデンティティやアクティブなセッションが自動的に引き継がれるとは想定しないでください。既存のユーザーがどのように再度サインインするか、また重複アカウントをどのように防ぐかを計画します。
  • 明示的に代替を計画していない限り、認可情報とアプリ固有のデータはローカルのデータモデルに保持してください。認証と認可は別々の移行作業が必要になることがよくあります。

カットオーバー前にテストする

  • 代表的で機密性のないアカウントとデータを使用して、非本番環境でテストします。
  • 既存のアカウントとしてサインインし、ダッシュボード、プロフィール、保存済みアイテムなど、ユーザー固有のデータを読み取るページを開きます。
  • 認可ルール、アカウント復旧、サインアウト、新規アカウントフローを検証します。
  • カットオーバー中は重複レコードとアクセス障害を監視します。検証が完了するまでロールバック計画を維持してください。

サポートを受ける

  • カスタム認証システムをReplit管理のClerk Authに移行する必要がある場合は、本番アカウントデータを変更する前にReplitサポートにお問い合わせください。
  • 別のプロバイダーで認証を管理している場合は、そのプロバイダーの最新の移行ドキュメントを使用し、カットオーバー前にアイデンティティマッピングを検証してください。

追加リソース