Auth モジュール
base44.auth を介したユーザー認証、登録、セッション管理。
目次
TypeScript の型
User インターフェース
LoginResponse インターフェース
パラメーターインターフェース
RegisterParams
VerifyOtpParams
ResetPasswordParams
ChangePasswordParams
Provider 型
メソッド
モジュールインターフェース
メソッドリファレンス表
例
新規ユーザーの登録 (完全なフロー)
登録はログイン前にメール検証が必要です。完全なフロー:- Register - ユーザーアカウントを作成
- Verification email sent - ユーザーが OTP コードを受信
- Verify OTP - ユーザーがメールを検証するためにコードを入力
- Login - ユーザーがログイン可能になる
重要: ユーザーは OTP 検証を完了するまでログインできません。検証前に loginViaEmailPassword を呼び出すと失敗します。
メール/パスワードでログイン
OAuth プロバイダーでログイン
サポートされているプロバイダー:'google' (デフォルトで有効)、'microsoft'、'facebook'。Microsoft または Facebook を使用する前に、アプリの認証設定で有効化してください。
現在のユーザーを取得
ユーザープロフィールの更新
認証状態の確認
ログアウト
Logout はユーザーをサーバーサイドのログアウトエンドポイント (/api/apps/auth/logout) にリダイレクトして HTTP-only クッキーとセッションをクリアし、その後指定された URL (省略時は現在のページ) にリダイレクトします。ブラウザー環境が必要です。
保護されたルートのパターン
認証トークンの設定
アプリケーションへのユーザー招待
OTP 検証
パスワードリセットフロー
パスワードの変更
エラー処理
一般的なエラーシナリオ
auth モジュールはさまざまなエラーをスローする可能性があります。ここでは一般的なシナリオとその処理方法を示します:認証エラー (401/403)
検証エラー (400/422)
レート制限 (429)
汎用エラーハンドラー
認証プロバイダー
アプリダッシュボードで認証プロバイダーを構成します:利用可能なプロバイダー
組み込み (すべてのプラン):- Email/Password - デフォルト、常に有効
- Google - OAuth 認証
- Microsoft - OAuth 認証
- Facebook - OAuth 認証
- Okta
- Azure AD
- GitHub
OAuth プロバイダーの使用
- Google – デフォルトで有効。
- Microsoft – 使用前にアプリの認証設定で有効化してください。
- Facebook – 使用前にアプリの認証設定で有効化してください。
環境での可用性
フロントエンドの使用
バックエンド関数の使用
アプリの可視性
アプリ設定でアプリにアクセスできる人を制御します:公開アプリ
- 基本的なアクセスにログイン不要
- ユーザーは認証なしで公開コンテンツを閲覧可能
- 認証されたユーザーは追加機能/データを取得
プライベートアプリ
- 任意のコンテンツにアクセスするにはログインが必要
- 未認証ユーザーは自動的にログインにリダイレクト
- すべてのコンテンツはデフォルトで保護
制限事項
認証 UI オプション
- 推奨:
loginViaEmailPassword()とloginWithProvider()を使用してカスタムログイン/サインアップ UI を構築し、ユーザーエクスペリエンスとブランディングを完全に制御します - 代替:
redirectToLogin()は Base44 のホスト型認証ページを使用しますが、カスタマイズは限定的です
ホスト型ログイン (redirectToLogin 経由)
redirectToLogin()は同じページにログインとサインアップの両方のオプションを表示します- 別の
redirectToSignup()メソッドはありません - ユーザーはホストページ上でログイン/サインアップを切り替え可能
- ⚠️ 注意: より良いユーザーエクスペリエンスのためにカスタムログイン UI の構築を推奨します
パスワード要件
- 最小長と複雑性要件が強制されます
- 要件は API 経由で公開されません
- 要件を満たさない場合、検証エラーが返されます
レート制限
- 悪用を防ぐため、OTP リクエストはレート制限されます
- パスワードリセットリクエストはレート制限されます
- Turnstile 保護でログイン試行がレート制限される場合があります
トークン管理
- JWT はデフォルトで localStorage に自動的に保存されます
- トークンの有効期限とリフレッシュは API に公開されていません
- トークンの有効性を検証するには
me()またはisAuthenticated()を呼び出します
ベストプラクティス
1. 常にエラーを処理する
2. 保護されたアクションの前に認証を確認する
3. TypeScript で型安全性を使用する
4. 認証情報をハードコードしない
5. ユーザーにフィードバックを提供する
6. トークンの有効期限を優雅に処理する
7. カスタムログイン UI を構築する (推奨)
このページは AI を使用して翻訳されました。最も正確で最新の情報については、英語版 を参照してください。