Skip to main content

Depuración de una Rule

La propiedad consoleOut es una salida de registro generada por los clientes dentro de la plataforma Auth0 mediante Actions, Rules, Hooks, Extensions y DB ScriptsAuth0 recomienda usar la propiedad consoleOut solo con fines de prueba y depuración. No debe registrar datos personales ni otros datos confidenciales en la consola web, ya que la salida de registro incluirá esos datos.
Por lo general, puede depurar una Rule en tiempo de ejecución mediante el registro en la consola con la función console.log. Para obtener más información, consulte console.log() en MDN Web Docs. No hay depuración interactiva de una Rule disponible dentro de la plataforma Auth0 (aunque podría emplearse la técnica de automatización de pruebas descrita a continuación junto con alguna herramienta externa interactiva de depuración de código fuente).

Agregue comentarios en línea

Añadir suficientes comentarios en línea (es decir, //) o de bloque (es decir, /* */) a una Rule, especialmente en la funcionalidad que no resulte evidente a simple vista, es de gran utilidad tanto para depurar el código como para entenderlo, sobre todo porque en muchos casos la persona que implementó inicialmente una Rule no será la misma que deba mantenerla en el futuro.

Registro en tiempo real de Actions

De forma predeterminada, la salida del registro de la consola no está disponible durante la ejecución normal. Sin embargo, puede usar los registros en tiempo real de Actions para mostrar todos los registros de la consola en tiempo real de la extensibilidad implementada en un inquilino de Auth0. La visualización del registro de la consola en tiempo real incluye la salida de console.log, console.error y console.exception.

Habilitar y deshabilitar el registro de depuración

En un entorno de producción, no es deseable mantener siempre activado el registro de depuración; dadas las implicaciones de rendimiento asociadas a Rules, no sería prudente tenerlo habilitado de forma continua. Para obtener más información, consulte Prácticas recomendadas de rendimiento. Sin embargo, en un entorno de desarrollo o pruebas, resulta mucho más conveniente poder habilitarlo de forma más continua. Además, un registro de depuración excesivo podría generar una cantidad considerable de “ruido”, lo que dificultaría aún más la identificación de problemas. Modificar una Rule para habilitar o deshabilitar el registro de depuración en función del entorno sería engorroso y propenso a errores. En su lugar, se puede aprovechar el objeto de configuración del entorno para implementar un procesamiento condicional de una forma similar a la siguiente:
function NPClaims(user, context, callback) {
    /*
     * Esta Rule (https://auth0.com/docs/rules) se utiliza para derivar
     * las claims efectivas asociadas al Perfil de Usuario Normalizado:
     *   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) {
        /* Filtrar las identidades que no tienen ningún equivalente a
         * 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);
  }
En el ejemplo anterior, se ha creado una variable de configuración de entorno DEBUG, que puede establecerse en true o false según el entorno de ejecución (por ejemplo, producción, pruebas o desarrollo). Esta variable se usa para determinar cuándo se realiza el registro de depuración. Además, podría crearse una variable de configuración de entorno DEBUGLEVEL, por ejemplo, para controlar el nivel de registro de depuración (por ejemplo, detallado, medio o mínimo). El ejemplo anterior también muestra la declaración de una función con nombre. Para mayor comodidad, asignar un nombre a la función —mediante alguna convención de nomenclatura compacta y única— puede facilitar el análisis de diagnóstico. Las funciones anónimas dificultan, en situaciones de depuración, la interpretación de la pila de llamadas generada como resultado de cualquier condición de error excepcional, y asignar un nombre de función único soluciona este problema. Para obtener más información, consulta Prácticas recomendadas para el manejo de errores.

Análisis estático

El editor de Rules del ofrece una comprobación rudimentaria de la sintaxis y cierto análisis de la semántica de las Rules. Sin embargo, no incluye funciones de análisis estático de código más complejas, como la detección de sobrescrituras, bucles o vulnerabilidades. Para solucionarlo, considere usar herramientas de terceros, como JSHint, SonarJS o Coverity, junto con pruebas de Rules como parte de su proceso de automatización de la implementación. Para obtener más información, consulte Prácticas recomendadas de implementación.