When you’re running a public site you should always turn off the DEBUG setting. That will make your server run much faster, and will also prevent malicious users from seeing details of your application that can be revealed by the error pages.
Cuando estés ejecutando un sitio público debes desactivar siempre el parámetro de configuración :setting:`DEBUG. Esto hará que tu servidor se ejecute mucho más rápido y también evitará que los usuarios malintencionados vean detalles de tu aplicación que pueden revelarse en las páginas de errores.
However, running with DEBUG set to False means you’ll never see errors generated by your site – everyone will instead see your public error pages. You need to keep track of errors that occur in deployed sites, so Django can be configured to create reports with details about those errors.
Sin embargo, ejecutar con :setting:`DEBUG establecido en False significa que nunca verás errores generados por tu sitio – todos verán en su lugar las páginas de errores públicas. Necesitas seguir el rastro de los errores que ocurren en sitios desplegados para que Django pueda estar configurado para crear informes con detalles sobre esos errores.
When DEBUG is False, Django will email the users listed in the ADMINS setting whenever your code raises an unhandled exception and results in an internal server error (strictly speaking, for any response with an HTTP status code of 500 or greater). This gives the administrators immediate notification of any errors. The ADMINS will get a description of the error, a complete Python traceback, and details about the HTTP request that caused the error.
Cuando :setting:`DEBUG esté establecido en False, Django enviará por correo electrónico a los usuarios listados en el parámetro de configuración ADMINS cada vez que tu código levante una excepción no gestionada y cause un error del servidor interno (estrictamente hablando, para cualquier respuesta con un código de estado HTTP de 500 o mayor). Esto da a los administradores notificación inmediata de cualquier error. Los ADMINS obtendrán una descripción del error, un seguimiento completo de Python y detalles sobre la solicitud HTTP que causó el error.
Nota
Para enviar correos electrónicos, Django requiere algunas configuraciones que le indiquen cómo conectarse a su servidor de correo electrónico. Al menos, necesitará especificar EMAIL_HOST y posiblemente EMAIL_HOST_USER y EMAIL_HOST_PASSWORD, aunque otros parámetros pueden ser requeridos dependiendo de la configuración del servidor de correo electrónico. Consulte la documentación de configuraciones de Django para obtener una lista completa de los parámetros relacionados con correos electrónicos.
Por defecto, Django enviará correos electrónicos desde root@localhost. Sin embargo, algunos proveedores de correo rechazan todos los correos electrónicos desde esta dirección. Para utilizar una dirección de remitente diferente, modifique el parámetro SERVER_EMAIL.
Para activar este comportamiento, coloque las direcciones de correo electrónico de los destinatarios en la configuración ADMINS.
Ver también
Los correos electrónicos de errores del servidor se envían utilizando el marco de registro, por lo que puede personalizar este comportamiento mediante la personalización de su configuración de registro.
Django también puede estar configurado para enviar correos electrónicos sobre enlaces rotos (errores 404 «página no encontrada»). Django envía correos electrónicos sobre errores 404 cuando:
DEBUG es False;
La configuración MIDDLEWARE incluye la clase django.middleware.common.BrokenLinkEmailsMiddleware.
Si se cumplen estas condiciones, Django enviará correos electrónicos a los usuarios listados en la configuración MANAGERS cada vez que su código levanta un 404 y la solicitud tiene un referente. No envía correos electrónicos para 404s sin referente — esos son normalmente personas tecleando URLs rotas o bots web rotos. También ignora los 404 cuando el referente es igual a la URL solicitada, ya que este comportamiento proviene de bots web rotos también.
Nota
La clase BrokenLinkEmailsMiddleware debe aparecer antes de otros middleware que interceptan errores 404, como LocaleMiddleware o FlatpageFallbackMiddleware. Colóquela hacia la parte superior de su configuración MIDDLEWARE.
Puedes decir a Django que deje de informar sobre 404 particularmente ajustando la configuración de la IGNORABLE_404_URLS . Debe ser una lista de objetos de expresiones regulares compilados. Por ejemplo:
import re
IGNORABLE_404_URLS = [
re.compile(r"\.(php|cgi)$"),
re.compile(r"^/phpmyadmin/"),
]
En este ejemplo, un 404 para cualquier URL que termine con .php o .cgi no se informará. Lo mismo sucede con cualquier URL que comience con /phpmyadmin/.
El siguiente ejemplo muestra cómo excluir algunas URLs convencionales que los navegadores y los rastreadores solicitan con frecuencia:
import re
IGNORABLE_404_URLS = [
re.compile(r"^/apple-touch-icon.*\.png$"),
re.compile(r"^/favicon\.ico$"),
re.compile(r"^/robots\.txt$"),
]
(Nota que estos son expresiones regulares, por lo que ponemos una barra diagonal en frente de los puntos para escaparlos.)
Si deseas personalizar el comportamiento de la clase django.middleware.common.BrokenLinkEmailsMiddleware (por ejemplo, ignorando las solicitudes procedentes de rastreadores), debes sobrescribir sus métodos.
Ver también
Los errores 404 se registran utilizando el marco de registro. Por defecto, estos registros de registro se ignoran, pero puedes utilizarlos para informar sobre errores escribiendo un manipulador y configurando el registro adecuadamente:doc:<topics/logging> .
Advertencia
El filtrado de datos sensibles es un problema difícil, y es casi imposible garantizar que los datos sensibles no se filtren en un informe de error. Por lo tanto, los informes de errores deben estar disponibles solo para miembros del equipo confiables y debes evitar transmitir informes de errores sin cifrar a través de Internet (como por ejemplo mediante correo electrónico).
Los informes de error son realmente útiles para depurar errores, por lo que es generalmente útil registrar la mayor cantidad posible de información relevante sobre esos errores. Por ejemplo, Django registra por defecto el full traceback para la excepción levantada, cada traceback frame’s variables locales y los HttpRequest’s attributes .
Sin embargo, en ocasiones ciertos tipos de información pueden ser demasiado sensibles y por lo tanto no ser apropiados para seguir su rastro, por ejemplo la contraseña de un usuario o el número de tarjeta de crédito. Por lo tanto, además de filtrar las configuraciones que parecen ser sensibles como se describe en la documentación de DEBUG, Django ofrece una serie de decoradores de funciones para ayudarte a controlar qué información debe ser filtrada de los informes de errores en un entorno de producción (es decir, donde DEBUG está establecido en False): sensitive_variables() y sensitive_post_parameters().
Si una función (ya sea una vista o cualquier llamado de retorno) en tu código utiliza variables locales susceptibles de contener información sensible, puedes evitar que los valores de esas variables se incluyan en los informes de errores utilizando el decorador sensitive_variables:
from django.views.decorators.debug import sensitive_variables
@sensitive_variables("user", "pw", "cc")
def process_info(user):
pw = user.pass_word
cc = user.credit_card_number
name = user.name
...
En el ejemplo anterior, los valores para las variables user, pw y cc serán ocultados y reemplazados con estrellas (**********) en los informes de errores, mientras que el valor de la variable name será revelado.
Para ocultar sistemáticamente todas las variables locales de una función de los registros de error, no proporciones ningún argumento al decorador sensitive_variables:
@sensitive_variables()
def my_function(): ...
Al utilizar múltiples decoradores
Si la variable que deseas ocultar también es un argumento de función (por ejemplo “user’ en el siguiente ejemplo), y si la función decorada tiene varios decoradores, asegúrate de colocar @sensitive_variables en la parte superior de la cadena de decoradores. De esta manera también ocultará el argumento de función como se pasa a través de los otros decoradores:
@sensitive_variables("user", "pw", "cc")
@some_decorator
@another_decorator
def process_info(user): ...
Si una de tus vistas recibe un objeto HttpRequest con parámetros POST susceptibles de contener información sensible, puedes evitar que los valores de esos parámetros se incluyan en los informes de errores utilizando el decorador sensitive_post_parameters:
from django.views.decorators.debug import sensitive_post_parameters
@sensitive_post_parameters("pass_word", "credit_card_number")
def record_user_profile(request):
UserProfile.create(
user=request.user,
password=request.POST["pass_word"],
credit_card=request.POST["credit_card_number"],
name=request.POST["name"],
)
...
En el ejemplo anterior, los valores para los parámetros POST pass_word y credit_card_number serán ocultados y reemplazados con estrellas (**********) en la representación del pedido dentro de los informes de errores, mientras que el valor del parámetro name será revelado.
Para ocultar sistemáticamente todos los parámetros POST de una solicitud en los informes de error, no proporciones ningún argumento al decorador sensitive_post_parameters:
@sensitive_post_parameters()
def my_view(request): ...
Todos los parámetros POST se filtran sistemáticamente de los informes de errores para ciertas vistas django.contrib.auth.views (login, password_reset_confirm, password_change, y add_view y user_change_password en el administrador auth) para prevenir la fuga de información sensible como contraseñas de usuarios.
Todos los decoradores sensibles_variables() y sensibles_post_parametros() hacen, respectivamente, anotar la función decorada con los nombres de las variables sensibles y anotan el objeto HttpRequest con los nombres de los parámetros POST sensibles, para que esta información sensible pueda ser filtrada más tarde de los informes de errores cuando ocurra un error. El filtro real se hace mediante el filtro de Django por defecto: django.views.debug.SafeExceptionReporterFilter. Este filtro utiliza las anotaciones de los decoradores para reemplazar los valores correspondientes con estrellas (**********) cuando se producen los informes de errores. Si deseas sobreescribir o personalizar este comportamiento por defecto para tu sitio entero, necesitas definir tu propia clase de filtro y decirle a Django que la utilice mediante el parámetro DEFAULT_EXCEPTION_REPORTER_FILTER:
DEFAULT_EXCEPTION_REPORTER_FILTER = "path.to.your.CustomExceptionReporterFilter"
También puedes controlar de manera más detallada qué filtro utilizar dentro de cualquier vista estableciendo el atributo exception_reporter_filter del objeto HttpRequest
def my_view(request):
if request.user.is_authenticated:
request.exception_reporter_filter = CustomExceptionReporterFilter()
...
Tu clase de filtro personalizada necesita heredar de django.views.debug.SafeExceptionReporterFilter y puede sobreescribir los siguientes atributos y métodos:
El valor de cadena para reemplazar el valor sensible con. Por defecto, reemplaza los valores de las variables sensibles con estrellas (**********).
Un objeto regular compilado utilizado para coincidir con los valores de configuración y request.META considerados como sensibles. Por defecto equivalente a:
import re
re.compile(r"API|AUTH|TOKEN|KEY|SECRET|PASS|SIGNATURE|HTTP_COOKIE", flags=re.IGNORECASE)
La palabra AUTH se agregó.
Devuelve True para activar el filtrado en get_post_parameters() y get_traceback_frame_variables(). Por defecto, el filtro está activo si DEBUG es False. Ten en cuenta que los valores request.META sensibles se filtran siempre junto con los valores de configuración sensibles, como se describe en la documentación del parámetro DEBUG.
Devuelve el diccionario filtrado de parámetros POST. Los valores sensibles se reemplazan con cleansed_substitute.
Devuelve el diccionario filtrado de variables locales para la ventana de seguimiento dada. Los valores sensibles se reemplazan con cleansed_substitute.
Si necesitas personalizar los informes de errores más allá del filtrado, puedes especificar una clase de informador de errores personalizada definiendo la configuración DEFAULT_EXCEPTION_REPORTER
DEFAULT_EXCEPTION_REPORTER = "path.to.your.CustomExceptionReporter"
El informador de excepciones es responsable de compilar los datos del informe de excepción y formatearlo como texto o HTML según sea necesario. (El informador de excepciones utiliza DEFAULT_EXCEPTION_REPORTER_FILTER cuando prepara los datos del informe de excepción.)
Tu clase de informador personalizada necesita heredar de django.views.debug.ExceptionReporter.
Propiedad que devuelve un objeto pathlib.Path representando la ruta absoluta del sistema de archivos a un template para renderizar la representación HTML de la excepción. Por defecto, utiliza el template proporcionado por Django.
Propiedad que devuelve un objeto pathlib.Path representando la ruta absoluta del sistema de archivos a un template para renderizar la representación en texto plano de la excepción. Por defecto, utiliza el template proporcionado por Django.
Devuelve un diccionario conteniendo información sobre las trazas de error.
Este es el punto principal de extensión para personalizar los informes de excepciones, por ejemplo:
from django.views.debug import ExceptionReporter
class CustomExceptionReporter(ExceptionReporter):
def get_traceback_data(self):
data = super().get_traceback_data()
# ... remove/add something here ...
return data
Con la clase de filtro, puedes controlar qué clase de reporte de excepciones utilizar dentro de cualquier vista estableciendo el atributo exception_reporter_class del objeto HttpRequest.
def my_view(request):
if request.user.is_authenticated:
request.exception_reporter_class = CustomExceptionReporter()
...
Ver también
Puedes configurar también la notificación de errores personalizados escribiendo un fragmento de middleware de excepción personalizado:ref:exception-middleware <exception-middleware>. Si lo haces, es una buena idea emular el manejo de errores incorporado de Django y solo informar/enviar los errores si DEBUG está en False.
may 31, 2026