メインコンテンツへスキップ

Before you start

  1. テナントにカスタムドメイン が構成されていることを確認します。
  2. すべてのサインアップとログインのプロンプトにユニバーサルログイン が使用されており、ログインプロンプトに**[Customize Login Page(ログインページのカスタマイズ)]** が無効になっていることを確認します。
  3. [Custom Page Template(カスタムページテンプレート)]が構成されていることを確認します。
サインアップとログインプロンプトのカスタマイズ 機能によって、カスタムドメインとカスタムページテンプレートが有効になっている顧客は、カスタムフィールドとコンテンツをアプリのサインアップとログインプロンプトに追加することができます。

ユースケース

サインアップとログインプロンプトのカスタマイズでは、custom contentdata capture という2つのユースケースに対応しています。 カスタムコンテンツ とは、テキストやリンク、画像などサインアップとログインプロンプトに直接配置された静的コンテンツのことです。 データキャプチャー は、サインアップとログインプロンプトに動的に追加されたフォーム要素を使用します。データキャプチャーは、ユーザーコンテンツや苗字などユーザーが生成したデータの収集と検証に役立ちます。データキャプチャーを利用できるのは、Passkeyを持っていないDatabase Connections認証ユーザーのみです。
機密性の高いデータや規制されたデータを伝達または収集する際は、Oktaとの契約に基づいて許可されている場合に限り、サインアッププロンプトとログインプロンプトのカスタマイズ機能を使用できます。
Prompt(プロンプト) とは、ある認証フローでの特定のステップのことです。プロンプトにはそれぞれ、少なくとも1つのScreen(スクリーン) があり、テナントの構成に応じて、対応するスクリーンには4つか6つのEntry Points(エントリーポイント) カスタムコード(Partials(パーシャル) )が挿入可能なスクリーン内の場所を指します。

用語

カスタマイズできるプロンプトは以下のとおりです。 パーシャルは、条件ロジックと動的変数を使用できるよう、HTML、CSS、Javascript、およびLiquid構文に対応しています。さらに、Page Template(ページテンプレート)にあるLiquid変数も使用することができます。
  • signup
  • signup-id
  • signup-password
  • login(ログイン)
  • login-id
  • login-password
  • login-passwordless
    • login-passwordless-sms-otp
    • login-passwordless-email-code
これらのエントリーポイントはデータベース接続が有効な場合に使用できます。 以下のエントリーポイントは、少なくとも1つのソーシャルまたはエンタープライズ接続が有効な場合に使用できます。
  • form-content-start
  • form-content-end
  • form-footer-start
  • form-footer-end
| | |
| --- | --- | --- | | サインアップ | サインアップID | サインアップパスワード |
  • secondary-actions-start
  • secondary-actions-end
パーシャルは最大10,000文字で指定し、/v2/prompts/{prompts_name}/partialsAuth0 Management APIが管理することができます。プロンプトはそれぞれ、パーシャルを追加、更新、または削除するときに、スクリーンを指定する必要があります。以下の例は、プロンプトの既存のすべてのパーシャルを表示するために呼び出しを行ったものです。APIの呼び出しでエントリーポイントを参照する場合、ulp-container接頭辞が必要でないことに注意してください。

Management APIを使用してパーシャルを管理する

カスタムプロンプトは現在、Auth0のDeploy CLIツールまたはAuth0 CLIには対応していません。
サインアップとログインプロンプトのカスタマイズには、特定のHTMLフォーム要素に対して事前に構築されたスタイルとクライアント側の検証サポートが備わっています。以下の要素がサポートされています。
An image showing the command-line interface for Partials.

スタイルと検証フォームの入力

事前に構築された入力スタイルを使用するには、<div>内の希望するフォーム要素をulp-fieldクラスでラップします。同様に、事前に構築されたエラースタイルを使用するために、ulp-errorクラスを同じ<div>に追加します。ulp-error-info要素が存在する場合は、スタイル設定されたエラーメッセージも表示されます。
  • <input type="text">
  • <input type="number">
  • <input type="checkbox">
  • <input type="password">
  • <input type="email">
  • <input type="tel">
  • <input type="url">
  • <select>
  • <textarea>
機能のクライアント側検証フレームワークを使用すると、顧客はHTML属性を使ってユーザー入力を検証し、1つ以上のカスタム検証機能を実行することができます。検証機能はパーシャルに直接含まれているか、ページテンプレートの<head>に含まれています。

クライアント側検証

クライアント側検証をフォーム要素に追加するには、以下のようにします。
  • <div class="ulp-error-info">要素のdata-ulp-validation-function属性を使用して、検証機能を参照します。
  • どのDOMイベント上で、検証機能を<div class="ulp-error-info">要素のdata-ulp-validation-event-listeners属性を使用して実行する必要があるかを宣言します。検証は提出時に自動的に実行されることに注意します。
サインアップページでサードパーティのJavaScriptを使用する際は、十分に注意してください。サインアップページは、セキュリティ関連の機密情報を扱うことが多いため、クロスサイトスクリプティング攻撃に対して脆弱です。ユーザーから提供されたデータは、可能な限り、検証してから送信することをお勧めします。
パーシャルコンテンツをローカライズするには、カスタムテキストAPIを使用して、新しいカスタムテキスト変数を定義します。スクリーン/言語の組み合わせごとに定義できるカスタムテキスト変数の数は最大30です。

コンテンツをローカライズする

カスタムテキストAPIはこちらから入手でき、各変数はvar-<name>命名規則に従っています。APIへの呼び出しは、カスタムテキスト変数を追加、更新、または削除するときに、Screen(スクリーン)を指定する必要があります。マークダウンリンクはサポートされており、ユーザーに表示される前にHTML <a>要素に変換されます。
カスタムテキスト変数を作成または更新する
以下は、利用規約チェックボックスのラベルのテキストの変数を英語とスペイン語で追加するための呼び出し例です。詳細については、を参照してください。
カスタムテキスト変数は、prompts.screen.textオブジェクトを使用して、パーシャルで参照されます。前のセクションで示したvar-tosの例に対する参照は、prompt.screen.texts.varTosです。Signup ID Prompt,(サインアップIDプロンプト)のパーシャルで前に作成した変数を使用する方法の例については、以下を参照してください。Management APIのvar-tos変数がパーシャルでvarTosとして参照されることに注意します。
カスタムテキスト変数をパーシャルで使用する
カスタムフォーム要素でキャプチャーしたデータはActions(アクション)で使用できます。Auth0では、収集したデータを検証することを推奨します。

キャプチャーしたデータを検証して保存する

フォームにカスタムの要素を使用する場合は、データをアクションで使用できるように、入力名にulp-プレフィックスを含める必要があります。
Actionはそれぞれ、キャプチャしたデータをevent.request.body上のオブジェクトとして受け取ります。顧客は、api.validation.error関数を使用して、検証エラーを返すことができます。
フォームで収集したデータは、保存やレンダリングする前に必ずサニタイズしてください。
  • 保存されたデータがすべてLiquidのヘルパー関数を通過していることを確認します
  • メールテンプレートのデータをレンダリングする際には、Liquid構文を削除します
  • Webページでデータをレンダリングする際には、HTMLエンティティをエスケープします
  • データベースにデータを保存する際には、パラメーター化クエリを使用します
  • クエリ文字列にデータを渡す場合には、たとえば、{{encodeURI}}または{{encodeURIParam}}を用いてエンコードします
リスクの軽減に関する詳細とデータを安全に保存するベストプラクティスについては、こちらのチートシートを参照してください。
Actionから、キャプチャーされたデータは外部APIに送信されて検証および保管されるか、api.user.setUserMetadataを通じてユーザーのuser_metadataに保存されます。
  • サインアッププロンプトからのデータは、ユーザー登録前トリガーでアクセスできます。検証エラーが返さると、ユーザーは登録できません。
  • ログインプロンプトからのデータは、ログイン後トリガーでアクセスできます。検証エラーが返されると、顧客のアプリケーションのエラーページに転送されます。
  • サインアッププロンプトとログインプロンプトからのデータはどちらもログイン後トリガーでアクセスできます。検証エラーが返されると、顧客のアプリケーションのエラーページに転送されます。
フォームで収集したデータは、保存やレンダリングする前に必ずサニタイズしてください。
  • 保存されたデータがすべてLiquidのヘルパー関数を通過していることを確認します
  • メールテンプレートのデータをレンダリングする際には、Liquid構文を削除します
  • Webページでデータをレンダリングする際には、HTMLエンティティをエスケープします
  • データベースにデータを保存する際には、パラメーター化クエリを使用します
  • クエリ文字列にデータを渡す場合には、たとえば、{{encodeURI}}または{{encodeURIParam}}を用いてエンコードします
リスクの軽減に関する詳細とデータを安全に保存するベストプラクティスについては、こちらのチートシートを参照してください。
ユーザーメタデータに保存する
取得したデータは検証と保管のためにActionから外部APIに送信されるか、api.user.setUserMetadataを通してユーザーのuser_metadataに保存されます。

もっと詳しく