Skip to main content

​
ルール のデバッグ

consoleOut プロパティは、Auth0 プラットフォーム内で Actions、Rules、Hooks、Extensions、DB Scripts を通じてお客様が生成したログ出力です。 Auth0 では、consoleOut プロパティはテストおよびデバッグの目的にのみ使用することを推奨しています。個人データやその他の機微データを Web コンソールに記録しないでください。記録すると、そのようなデータがログ出力に含まれます。
通常、ルール の実行時デバッグ は、console.log を使ったコンソールログ出力によってそのまま行えます。詳しくは、MDN Web Docs の console.log() を参照してください。Auth0 プラットフォーム内では、ルール のインタラクティブなデバッグは利用できません (ただし、以下で説明するテスト自動化の手法を、外部のインタラクティブなソースデバッグ機能と組み合わせて使用することは可能です) 。

​
行コメントを追加する

ルールには、十分な行コメント (//) やブロックコメント (/* */) を追加しておくことが重要です。特に、見ただけでは分かりにくい処理の周辺では、デバッグだけでなくコードの理解にも大いに役立ちます。ルールの初期実装者と、その後の保守担当者が同一人物とは限らないケースが多いためです。

​
Actions のリアルタイムログ

デフォルトでは、通常の実行時にコンソールログ出力は表示されません。ただし、Actions のリアルタイムログを使用すると、Auth0 テナントに実装された拡張機能について、すべてのコンソールログをリアルタイムで表示できます。リアルタイムのコンソールログ表示には、console.log の出力、console.error の出力、console.exception の出力が含まれます。

​
デバッグログの有効化と無効化

本番環境では、デバッグログを常時有効にしておくことは望ましくありません。ルール に伴うパフォーマンス上の考慮事項もあるため、継続的に有効化するのは賢明ではありません。詳細については、パフォーマンスのベストプラクティスを参照してください。 一方、開発環境やテスト環境では、より継続的に有効化できるほうが望ましい場合が多くあります。さらに、デバッグログが多すぎると大量の「ノイズ」が発生し、問題の特定がかえって難しくなる可能性があります。 環境に応じてデバッグログの有効/無効を切り替えるために ルール を変更すると、煩雑でミスも起こりやすくなります。代わりに、環境設定オブジェクトを活用することで、次のように条件付き処理を実装できます。 
function NPClaims(user, context, callback) {
    /*
     * このルール (https://auth0.com/docs/rules) は、正規化ユーザープロファイルに
     * 関連する有効なクレームを導出するために使用されます:
     *   https://auth0.com/docs/user-profile/normalized/auth0
     */
    var LOG_TAG = '[NORMALIZED_PROFILE_CLAIMS]: ';
    var DEBUG = configuration.DEBUG ? console.log : function () {};
    DEBUG(LOG_TAG, "identities=", user.identities);
    user.user_metadata = user.user_metadata || {};

    //
    user.family_name =
      user.family_name ||
      user.identities.filter(function(identity) {
        /* Family Name に相当する情報を持たない
         * アイデンティティを除外する
         */
        return(
          identity.profileData &&
          identity.profileData.family_name);
      }).map(function(identity) {
        return identity.profileData.family_name;
      })[0];
    DEBUG(LOG_TAG, "Computed user.family_name as '", user.family_name, "'");
      .
      .

    //
    return callback(null, user, context);
  }
上記の例では、DEBUG 環境設定変数を作成しています。この変数は、実行環境 (例: 本番、テスト、開発) に応じて true または false に設定できます。この変数の設定を使って、デバッグログを出力するタイミングを判断します。さらに、たとえば DEBUGLEVEL 環境 configuration 変数を作成し、デバッグログレベル (例: 詳細、中程度、最小限) を制御することもできます。 上記の例では、名前付き関数の宣言も示しています。簡潔で一意の命名規則に従って関数名を付けておくと、診断時の分析に役立ちます。匿名関数を使うと、例外的なエラー状態によって生成されたコールスタックをデバッグ時に解釈しにくくなりますが、一意の関数名を付けることでこの問題に対処できます。詳しくは、Error Handling Best Practices を参照してください。

​
静的解析

のルールエディターでは、基本的な構文チェックとルールのセマンティクス解析を行えます。ただし、上書き検出、ループ検出、脆弱性検出といった、より高度な静的コード解析は提供されていません。そのため、デプロイ自動化プロセスの一環としてルールのテストとあわせて、JSHint、SonarJS、Coverity などのサードパーティツールの活用を検討してください。詳細については、デプロイのベストプラクティス を参照してください。