Signalement d’erreursLien vers cette rubrique#

Erreurs de serveurLien vers cette rubrique#

Lorsque DEBUG vaut False, Django envoie un courriel aux utilisateurs énumérés dans le réglage ADMINS à chaque fois que le code génère une exception non interceptée produisant une erreur interne de serveur (code d’état HTTP 500). Les administrateurs sont ainsi notifiés immédiatement à la suite de toute erreur. Les personnes dans ADMINS obtiennent une description de l’erreur, une trace Python complète ainsi que des détails sur la requête HTTP qui a causé l’erreur.

Par défaut, Django envoie ses messages avec l’adresse d’origine root@localhost. Toutefois, certains fournisseurs de messagerie rejettent tous les messages provenant de cette adresse. Pour utiliser une adresse d’expéditeur différente, modifiez le réglage SERVER_EMAIL.

Pour activer ce comportement, placez les adresses électroniques des destinataires dans le réglage ADMINS.

Erreurs 404Lien vers cette rubrique#

Django peut aussi être configuré pour envoyer des courriels pour des erreurs de lien cassé (erreurs 404 « page non trouvée »). Django envoie des courriels lors d’erreurs 404 si :

• DEBUG vaut False;

• Votre réglage MIDDLEWARE_CLASSES contient django.middleware.common.BrokenLinkEmailsMiddleware.

Si ces conditions sont remplies, Django envoie un courriel aux utilisateurs mentionnés dans le réglage MANAGERS chaque fois que le code signale une erreur 404 et que la requête possède une URL référente (« referer »). Il ne prend pas la peine d’envoyer un courriel pour une erreur 404 sans URL référente, car il s’agit généralement de personnes ayant mal saisi une adresse ou de robots Web défectueux. Il ignore aussi les erreurs 404 lorsque l’URL référente est la même que l’URL demandée, car ce comportement est aussi typique des robots Web défectueux.

Il est possible d’indiquer à Django de ne pas signaler certaines erreurs 404 en ajustant le réglage IGNORABLE_404_URLS. Celui-ci est une liste d’expressions régulières compilées. Par exemple :

import re
IGNORABLE_404_URLS = [
    re.compile(r'\.(php|cgi)$'),
    re.compile(r'^/phpmyadmin/'),
]

Dans cet exemple, une erreur 404 vers toute URL se terminant par .php ou .cgi ne sera pas signalée. Ni aucune URL commençant par /phpmyadmin/.

L’exemple suivant montre comment exclure certaines URL conventionnellement demandées par les navigateurs et les robots :

import re
IGNORABLE_404_URLS = [
    re.compile(r'^/apple-touch-icon.*\.png$'),
    re.compile(r'^/favicon\.ico$'),
    re.compile(r'^/robots\.txt$'),
]

(Notez qu’il s’agit d’expressions régulières, d’où la présence de la barre oblique inverse devant les points pour les échapper.)

Si vous souhaitez personnaliser davantage le comportement de django.middleware.common.BrokenLinkEmailsMiddleware (par exemple pour ignorer les requêtes en provenance de robots Web), vous devez créer une sous-classe et surcharger ses méthodes.

Filtrage des informations sensiblesLien vers cette rubrique#

Les rapports d’erreur sont vraiment utiles pour déboguer les erreurs, il est donc généralement utile de récolter le maximum d’informations à leur sujet. Par défaut, Django récolte une trace complète de l’exception levée, les variables locales de chaque contexte de trace et les attributs de l’objet HttpRequest.

However, sometimes certain types of information may be too sensitive and thus may not be appropriate to be kept track of, for example a user’s password or credit card number. So in addition to filtering out settings that appear to be sensitive as described in the DEBUG documentation, Django offers a set of function decorators to help you control which information should be filtered out of error reports in a production environment (that is, where DEBUG is set to False): sensitive_variables() and sensitive_post_parameters().

sensitive_variables(*variables)Lien vers cette définition#

Si une fonction (une vue ou toute autre fonction de rappel) de votre code utilise des variables locales susceptibles de contenir des informations sensibles, vous pouvez empêcher les valeurs de ces variables d’apparaître dans les rapports d’erreur en utilisant le décorateur sensitive_variables:

Code

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
    ...

Dans l’exemple ci-dessus, les valeurs des variables user, pw et cc seront masquées et remplacées par des étoiles (**********) dans les rapports d’erreur, tandis que la valeur de la variable name sera visible.

Pour masquer systématiquement toutes les variables locales d’une fonction dans les journaux d’erreurs, n’indiquez aucun paramètre au décorateur sensitive_variables:

Code

@sensitive_variables()
def my_function():
    ...

sensitive_post_parameters(*parameters)Lien vers cette définition#

Si l’une de vos vues reçoit un objet HttpRequest avec des paramètres POST susceptibles de contenir des informations sensibles, vous pouvez empêcher les valeurs de ces paramètres d’apparaître dans les rapports d’erreur en utilisant le décorateur sensitive_post_parameters:

Code

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'],
    )
    ...

Dans l’exemple ci-dessus, les valeurs des paramètres POST pass_word et credit_card_number seront masquées et remplacées par des étoiles (**********) dans la représentation de la requête dans le rapport d’erreur, tandis que la valeur du paramètre name sera visible.

Pour masquer systématiquement tous les paramètres POST d’une requête dans les rapports d’erreur, n’indiquez aucun paramètre au décorateur sensitive_post_parameters:

Code

@sensitive_post_parameters()
def my_view(request):
    ...

Tous les paramètres POST sont systématiquement masqués dans les rapports d’erreur pour certaines vues django.contrib.auth.views ( login, password_reset_confirm, password_change et add_view, ainsi que user_change_password dans l’administration de auth) pour empêcher la divulgation d’informations sensibles comme les mots de passe.

Rapports d’erreur personnalisésLien vers cette rubrique#

Tout ce que font sensitive_variables() et sensitive_post_parameters(), c’est respectivement annoter la fonction décorée avec les noms des varaibles sensibles et annoter l’objet HttpRequest avec les noms des paramètres POST sensibles, afin que ces informations sensibles puissent être plus tard filtrées des rapports lorsqu’une erreur se produit. Le vrai filtrage est effectué par le filtre de rapport d’erreur par défaut de Django, django.views.debug.SafeExceptionReporterFilter. Ce filtre utilise les annotations des décorateurs pour remplacer les valeurs correspondantes par des étoiles (**********) au moment de la production du rapport d’erreur. Si vous souhaitez surcharger ou personnaliser ce comportement par défaut pour tout votre site, vous devez définir votre propre classe de filtre et indiquer à Django de l’utiliser par le moyen du réglage DEFAULT_EXCEPTION_REPORTER_FILTER:

DEFAULT_EXCEPTION_REPORTER_FILTER = 'path.to.your.CustomExceptionReporterFilter'

Vous pouvez aussi contrôler d’une manière plus fine le filtre qu’une vue données doit utiliser en définissant l’attribut exception_reporter_filter de l’objet HttpRequest.

def my_view(request):
    if request.user.is_authenticated():
        request.exception_reporter_filter = CustomExceptionReporterFilter()
    ...

Votre classe de filtre personnalisée doit hériter de django.views.debug.SafeExceptionReporterFilter et peut surcharger les méthodes suivantes :

class SafeExceptionReporterFilterLien vers cette définition#

SafeExceptionReporterFilter.is_active(request)Lien vers cette définition#

Renvoie True pour activer le filtrage opéré par les autres méthodes. Par défaut, le filtrage est actif si DEBUG vaut False.

SafeExceptionReporterFilter.get_post_parameters(request)Lien vers cette définition#

Renvoie le dictionnaire des paramètres POST filtré. Par défaut, il remplace les valeurs des données sensibles par des étoiles (**********).

SafeExceptionReporterFilter.get_traceback_frame_variables(request, tb_frame)Lien vers cette définition#

Renvoie le dictionnaire filtré des variables locales du contexte de trace donné. Par défaut, il remplace les valeurs des variables sensibles par des étoiles (**********).