Lorsque vous faites fonctionner un site public, vous devriez toujours désactiver le réglage DEBUG. Cela va accélérer le serveur et évitera aussi que des utilisateurs mal intentionnés puissent voir des détails de l’application pouvant être révélés dans les pages d’erreur.
Cependant, lorsqu’un site fonctionne avec DEBUG réglé à False, vous ne verrez jamais les détails des erreurs générés par le site ; tout le monde voit les mêmes pages d’erreur publiques. Il est nécessaire de garder la trace des erreurs qui se produisent sur des sites en production, il est donc possible de configurer Django pour qu’il crée des rapports incluant les détails de ces erreurs.
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.
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 :
\nDEBUG vaut False;
Votre réglage MIDDLEWARE 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\nIGNORABLE_404_URLS = [\n re.compile(r'\\.(php|cgi)$'),\n re.compile(r'^/phpmyadmin/'),\n]\nDans 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 :
\nimport re\nIGNORABLE_404_URLS = [\n re.compile(r'^/apple-touch-icon.*\\.png$'),\n re.compile(r'^/favicon\\.ico$'),\n re.compile(r'^/robots\\.txt$'),\n]\n(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.)
\nSi 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.
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.
Il peut cependant arriver que certains types d’information soient trop sensibles et qu’il n’est pas adéquat d’en conserver la trace, par exemple un mot de passe ou un numéro de carte de crédit. En plus d’exclure les réglages apparaissant comme sensibles selon ce qui est expliqué dans la documentation de DEBUG, Django offre donc un ensemble de fonctions décoratrices pour vous aider à contrôler les informations qui ne devraient pas apparaître dans les rapports d’erreur dans un environnement de production (c’est-à-dire quand DEBUG est défini à False) : sensitive_variables() et sensitive_post_parameters().
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:
from django.views.decorators.debug import sensitive_variables\n\n@sensitive_variables('user', 'pw', 'cc')\ndef process_info(user):\n pw = user.pass_word\n cc = user.credit_card_number\n name = user.name\n ...\nDans 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:
@sensitive_variables()\ndef my_function():\n ...\nSi 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:
from django.views.decorators.debug import sensitive_post_parameters\n\n@sensitive_post_parameters('pass_word', 'credit_card_number')\ndef record_user_profile(request):\n UserProfile.create(\n user=request.user,\n password=request.POST['pass_word'],\n credit_card=request.POST['credit_card_number'],\n name=request.POST['name'],\n )\n ...\nDans 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:
@sensitive_post_parameters()\ndef my_view(request):\n ...\nTous 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.
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'\nVous 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):\n if request.user.is_authenticated:\n request.exception_reporter_filter = CustomExceptionReporterFilter()\n ...\nVotre classe de filtre personnalisée doit hériter de django.views.debug.SafeExceptionReporterFilter et peut surcharger les méthodes suivantes :
Renvoie True pour activer le filtrage opéré par les autres méthodes. Par défaut, le filtrage est actif si DEBUG vaut False.
Renvoie le dictionnaire des paramètres POST filtré. Par défaut, il remplace les valeurs des données sensibles par des étoiles (**********).
\nRenvoie le dictionnaire filtré des variables locales du contexte de trace donné. Par défaut, il remplace les valeurs des variables sensibles par des étoiles (**********).
\n