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

​
ルールのデバッグ

consoleOutプロパティは、Auth0プラットフォーム内でActions、Rules、Hooks、拡張機能、DBスクリプトを通じて顧客によって生成されるログ出力です。Auth0 では、consoleOutプロパティをテストとデバッグの目的でのみ使用することを推奨しています。個人データや他の機密データをWebコンソールに記録したり、ログ出力にそれらのデータを含めたりしてはいけません。
通常、デフォルトでは、console.log機能を使用してコンソールログに記録することで、実行時にルールをデバッグします。詳細については、MDN Web Docs の console.log()を参照してください。Auth0プラットフォーム内ではルールのインタラクティブなデバッグは利用できません（ただし、以下で説明するテスト自動化テクニックを外部のインタラクティブなソースデバッグ機能と組み合わせて使用​​することはできます。詳細については、ルールテストのベストプラクティスを参照してください）。

​
行コメントを追加する

ルールに十分な行（つまり、//）またはブロック（つまり、/* */）コメントを追加することは、特に、わかりにくい機能に関して、コードのデバッグとコードの理解の両方にとって非常に重要です。特に、ルールの最初の実装者と、その後の保守の責任者が必ずしも同じ人物ではない場合が多いためです。

​
リアルタイムWebtaskログ

デフォルトでは、通常の実行中にコンソールログ出力を表示することはできません。ただし、リアルタイム Webtaskログ拡張機能を使用すると、ルールを含む、Auth0テナントに実装されているすべての拡張機能のすべてのコンソールログをリアルタイムで表示できます。拡張機能によって提供されるリアルタイムコンソールログ表示には、すべてのconsole.log出力、console.error出力、およびconsole.exception出力が含まれます。詳細については、MDN Web Docsのconsole.error()をお読みください。

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

実稼働環境では、デバッグログは常に望ましいものではありません。ルールに関連するパフォーマンスを考慮すると、デバッグログを継続的に有効にしておくことは賢明ではありません。詳細については、「パフォーマンスのベストプラクティス」をお読みください。 ただし、開発環境やテスト環境では、より継続的に有効にするオプションの方がはるかに望ましいです。さらに、デバッグログを過剰に記録すると、かなりの「ノイズ」が発生し、問題の特定がさらに困難になる可能性があります。 環境に応じてデバッグログを有効または無効にするルールを変更すると、面倒になり、エラーが発生しやすくなります。詳細については、ルール環境のベストプラクティスをお読みください。代わりに、環境構成オブジェクトを活用して、次のような方法で条件付き処理を実装できます： 
function NPClaims(user, context, callback) {
    /*
     * This rule (https://auth0.com/docs/rules) is used to derive
     * effective claims associated with the Normalized User Profile:
     *   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) {
        /* Filter out identities which do not have anything synonymous with
         * 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変数を作成して、デバッグログレベル（詳細、中、スパースなど）を制御することもできます。 上記の例は、名前付き関数の宣言も示しています。便宜上、簡潔で一意の命名規則を使用して関数名を指定すると、診断分析に役立ちます。匿名関数を使用すると、デバッグ時に例外的なエラー状態の結果として生成されたコールスタックを解釈することが困難になるため、一意の関数名を提供することでこの問題に対処できます。詳細については、エラー処理ののベストプラクティスをお読みください。

​
静的分析

Auth0ダッシュボードのルールエディターでは、基本的な構文チェックとルールのセマンティクスの分析が提供されます。ただし、上書き検出、ループ検出、脆弱性検出などのより複雑な静的コード分析については規定されていません。これに対処するには、デプロイメント自動化プロセスの一環として、ルールテストと組み合わせて、JSHint、SonarJS、Coverityなどのサードパーティツールを活用することを検討してください。詳細については、導入のベストプラクティスをお読みください。

​
もっと詳しく

⌘I