No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Gestión avanzada de errores: Throw

13/29
Recursos

¿Cómo gestionar errores de seguridad en tu aplicación de manera eficiente?

En el mundo del desarrollo web, la gestión de errores es una cuestión crítica no solo para la estética sino también para la seguridad de una aplicación. Es vital impedir que potenciales atacantes obtengan información sobre el servidor o la aplicación a través de errores no manejados. Este contenido ofrece una guía práctica para gestionar errores en aplicaciones Node.js con Express, mejorando así la seguridad y utilidad de las respuestas de error.

¿Cómo centralizar la gestión de errores?

Centralizar la gestión de errores significa consolidar todos los manejadores de errores en un solo archivo o módulo para simplificar su gestión y control. En este caso, el archivo error.js es creado para este propósito.

// Crear el archivo error.js
const response = require('./response');

function handleErrors(err, req, res, next) {
    console.error('Error:', err);
    
    const message = err.message || 'Internal Error';
    const status = err.statusCode || 500;
    
    response.error(req, res, message, status);
}

module.exports = handleErrors;

¿Cómo integrar el manejador de errores en Express?

Una vez que se tiene un archivo dedicado para la gestión de errores, el siguiente paso es integrarlo dentro de Express como el último middleware. Esto garantiza que pueda capturar cualquier error que no haya sido manejado previamente.

// Integrar el manejador de errores en Express
const errors = require('./network/errors');

// Otros middlewares
app.use(errors);

¿Cómo personalizar los errores para mejorar las respuestas?

La personalización de errores permite que una aplicación responda de manera coherente y específica a cada tipo de error. Aquí se utiliza una estructura de errores personalizada para establecer códigos de estado y mensajes más útil.

// Crear una estructura de error personalizada
function CustomError(message, statusCode) {
    const error = new Error(message);
    error.statusCode = statusCode;
    return error;
}

module.exports = CustomError;

A su vez, al implementarlo en funcionalidad como autenticación, cambiar new Error por CustomError mejora significativamente la interpretación de los errores.

// Personalizar errores en funcionalidades específicas
const CustomError = require('../utils/error');

function authHandler(req, res, next) {
    const authorized = false; // Simulación de una condición

    if (!authorized) {
        return next(CustomError('No tienes privilegios para hacer esto', 401));
    }

    next();
}

Consejos prácticos:

  • Recordar la ubicación del middleware: Al integrar el middleware de errores, asegúrate de que sea el último que uses para evitar interrupciones en el flujo de ejecución.
  • Manejo diferencial de errores: No todos los errores deben responder con un estado 500 (Error del Servidor Interno), personaliza usando códigos como 401 (No Autorizado), 403 o 404 según la situación.
  • Ampliación según necesidad: Si requieres registrar detalles adicionales del error para fines de auditoría, puedes expandir la forma en que estructuras los errores en CustomError.

Implementar estas estrategias no solo mejora la seguridad de tu aplicación al esconder detalles potencialmente sensibles, sino que también mejora la experiencia del usuario al ofrecer respuestas más precisas y comprensibles en caso de errores. ¡Continúa explorando y perfeccionando estas prácticas para fortalecer tus aplicaciones!

Aportes 23

Preguntas 4

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Esta clase es magistral. Cada vez me doy cuenta de que no conozco nada jajaja

les comparto mi implementación del middleware de error

const Sentry = require('@sentry/node');
const debug = require('debug')('api:error');
const config = require('./../config');
const response = require('./../network/response');

const sentryUrl = `https://${config.sentry.dns}@sentry.io/${config.sentry.id}`;
Sentry.init({ dsn: sentryUrl });

function withErrorStack(err, stack) {
    if (config.dev) {
        return { ...err, stack }
    }
}

function logErrors(err, req, res, next) {
    Sentry.captureException(err);
    debug(err.stack);
    next(err);
}

function errorHandler(err, req, res, next) {
    const { statusCode } = err;
    response.error(req, res, withErrorStack(err, err.stack), statusCode);
}

module.exports = {
    logErrors,
    errorHandler,
}

en el curso de backend con node y el de passport js, se trabaja con un libreria @hapi, la cual tiene un modulo para el manejo de errores que es @hapi/boom y @hapi/joi para validaciones, con unas simples lineas se le da manejo al error, es muy practico, lo mismo con las validaciones.

La clase es buena aunque se agradecería que no repita nombres de archivos ya que eso genera mucha confusión. En utils tenemos error.js y en network tenemos errors.js

Por si alguien mas le da el mismo error que a mi, “app use requires a middleware” La solucion es la darle require se le coloca llaves:

const {errors} = require('../network/errors');

Usando custom error en lugar de throw new Error()

creando la fucnion error en la carpeta util, ya no haria falta el error.js de la carpeta network?

Fantástico ahora mi código está mucho más organizado con los cursos de carlos, que fácil es aprender Node con él.

Entiendo el uso del helper lo que no entiendo es porqué repetimos en network/response la misma logica del status code y status msg.

Ahora tenemos todos los errores centralizados dentro de utils/error, con lo cual no deberiamos llamar a network error sino llamar a utils/error y es este error catcheado por network error.

Podemos modificar entonces network/response la function error

exports.error = (req, res, message, status) => {
  res.status(status).send({
    error: true,
    status,
    body: message
  });
};

¿como funciona el next?

Definitivamente, muy buena clase

Fijesé que igual le devuelve un error:false cuando debería ser true, supongo que se solucionara en adelante.

Estoy super confundido con el archivo “secure” en users, hay una función “checkAuth” que recibe el parametro “action” y adentro “middleware” con los argumentos “req, res, next”. Si mal no entiendo, middleware se ejecuta cuando se devuelve al invocar checkAuth desde router.put, pero el único argumento es lo que afecta al switch, ¿los parámetros req, res y next cómo le llegan al middleware?

sacando brillo a el mundo magico de nodejs

Fantástico ahora mi código está mucho más organizado con los cursos de carlos, que fácil es aprender Node con él.

Excelente clase!

Yo uso esta librería desde cursos pasados, me parecio bastante buena. Se las comparto <https://hapi.dev/api/?v=21.3.3>

Para las personas que tengan dudas con los middlewares les dejo la documentación donde vienen explicadas algunas cosas así como el uso e implementación de ellos.

Me agrada como explica Carlos, pero marea un montón tantos archivos con el mismo nombre, el naming de archivos acá es más complicado que el código

Genial esta clase, el orden para realizar el proyecto me parece genial, aunque a veces al repetir algunos nombres en carpetas me he confundido, ese orden hace que el código en general sea más fácil de entender

Justo ese error, estaba pensando como solucionarlo

el middleware de errors que le pasamos a la app de express manejara todos los errores y excepciones no manejadas?