Skip to main content
RulesとHooksのサポート終了（EOL）日は2026年11月18日 であり、2023年10月16 日の時点で作成された新しいテナントは使用できなくなります。Hooksが有効な既存のテナントは、サポート終了までHooksを利用できます。今後はActionsに移行して、Auth0の機能を拡張することを強くお勧めします。Actionsを使用すると、豊富な情報やインラインドキュメント、パブリックnpmパッケージにアクセスして、外部統合を使って全体的な拡張エクスペリエンスを強化することができます。Actionsの詳細については、「Auth0 Actionsの仕組みを理解する」をお読みください。当社では、移行の参考資料として、RulesからActionsへの移行とHooksからActionsへの移行に関するガイドを提供しています。また、専用の「Actionsへの移行」ページでは、機能の比較やActionsのデモ、その他のリソースを掲載して、円滑な移行をサポートしています。RulesとHooksの廃止の詳細については、当社のブログ記事「RulesとHooksの提供終了について」をお読みください。
には、ルールをテストしてデバッグするために、ルールをTRY（試す）機能があります。この機能では、モックのuserとcontextオブジェクトを定義し、ルールに渡して実行することができます。ルールの実行が完了すると、結果の出力（コンソールのログを含む）が表示されます。これはルールの単体テストを一目で分かりやすいものにする反面、手動での作業がメインとなるため、Mochaやrewireなどのテスト自動化ツールは活用できません。 ベストプラクティスとして、また、SDLC（Software Development Life Cycle：ソフトウェア開発ライフサイクル）の推奨される対応として、運用環境への導入前にルールやルールの変更をテストする際には、Auth0で別のテスト用テナントを使用してください。

​
自動化

多少のボイラープレートを使用すれば、ルールがAuth0テナントに導入・実行され、変更することなく、CI/CD（継続的インテグレーションと継続的デプロイ）の自動化（単体）テスト環境で使用されるように実装できます。 
const vm = require('vm');
  const fs = require('fs');
  var user = {
      "name":        "jdoe@foobar.com",
      "email":       "jdoe@foobar.com",
      "user_id":     "auth0|0123456789",
          .
          .
    };
  var context = {
      "clientID":            "123456789",
      "clientName":          "MyWebApp",
      "connection":          "MyDbConn",
      "connectionStrategy":  "auth0",
      "protocol":            "oidc-basic-profile",
          .
          .
    };

  global.configuration = {
    DEBUG: true
  };

  vm.runInThisContext(
      "(()=>{return " + fs.readFileSync('./rules/Normalized Profile Claims.js') + " })();", {
        // filename for stack traces
        filename: 'Normalized Profile Claims.js',
        displayErrors: true
      }
  )(
    user,
    context,
    function callback() {
      console.log("Complete");
    }
  );
上の例が示すように、Node.jsのVMを使用すると、（独立したノードモジュールに）何らかの比較的単純なテストを実装して、ルールをテスト実行することができます。この例では、「Normalized Profile Claims（正規化プロファイルクレーム）」という名前のルールがファイルから読み込まれ、ルールの（JavaScript）コードの周りにボイラープレートが追加されて実行されます（ボイラープレートとは、ルールのコードを含んだファイルを読み込むファイルシステム呼び出しの前後に追加される文字列です）。 runInThisContextの呼び出しに渡されたオプションオブジェクトは、例外エラーが発生した際のデバッグに役立つ情報を提供します。この関数の呼び出しについては、Node.jsのドキュメントを参照してください。 ルールのテスト中に渡された最初の2つのオブジェクトはuserとcontextを表すオブジェクトです。これらはAuth0 DashboardのTRY（試す）機能と同様に、スタブで代用することができます。第3パラメーターのcallback関数は、パイプライン継続を模倣するように実装できるため、結果的に順序を追って後続のルールが実行されます。 渡されるcallback関数の中でテストを行うか、アサーションを検証することで、コールバック関数が少なくとも1回呼び出されることを検証できます。また、ルールがコールバックを複数回呼び出していないことを確認する実装を提供することもお勧めします。 さらに、Node.jsのglobalオブジェクトを使って、構成オブジェクトと、必要であればauth0オブジェクトのインスタンスにもアクセスすることができます。上の例では、（上のセクションでも説明したように）推奨基準に沿って、デバッグに役立つグローバルなconfigurationオブジェクトが定義されています。 また、上の例では、Auth0 Deploy CLIが提供するファイルシステムのディレクトリ構造を利用しています。Auth0 Deploy CLIはルールを導入するのに便利です。
⌘I