Question

J'utilise Django 1.0 et je suis sur le point de déployer mon application. En tant que tel, je changerai le paramètre DEBUG sur False.

Cela dit, j'aimerais quand même inclure le stacktrace sur ma page 500.html en cas d'erreur. Ce faisant, les utilisateurs peuvent copier-coller les erreurs et les envoyer facilement par courrier électronique aux développeurs.

Avez-vous des idées sur la meilleure façon d’aborder cette question?

Était-ce utile?

La solution

Enregistrez automatiquement vos 500, de cette façon:

  • Vous savez quand ils se produisent.
  • Vous n'avez pas besoin que les utilisateurs vous envoient des stacktraces.

Joel recommande même d’aller même jusqu’à créer automatiquement des tickets dans votre système de suivi des bogues lorsque votre application rencontre un échec. Personnellement, je crée un flux RSS (privé) avec les stacktraces, les URL, etc. auxquels les développeurs peuvent s'abonner.

En revanche, afficher les traces de la pile à vos utilisateurs peut entraîner la divulgation d'informations que des utilisateurs malveillants pourraient utiliser pour attaquer votre site. Les messages d’erreur trop détaillés sont l’une des étapes classiques des attaques par injection SQL.

Éditer (exemple de code ajouté pour capturer une trace):

Vous pouvez obtenir les informations sur l'exception à partir de l'appel sys.exc_info. Lors du formatage du suivi pour l’affichage, il provient du module de suivi:

import traceback
import sys

try:
    raise Exception("Message")
except:
    type, value, tb = sys.exc_info()
    print >> sys.stderr,  type.__name__, ":", value
    print >> sys.stderr, '\n'.join(traceback.format_tb(tb))

Impressions:

Exception : Message
  File "exception.py", line 5, in <module>
    raise Exception("Message")

Autres conseils

Comme le dit @zacherates, vous ne voulez vraiment pas afficher un stacktrace à vos utilisateurs. La solution la plus simple à ce problème est ce que Django fait par défaut si vous-même et vos développeurs sont répertoriés dans le paramètre ADMINS avec les adresses électroniques; il envoie un courrier électronique à toutes les personnes figurant dans cette liste avec le suivi complet de la pile (et plus) chaque fois qu'une erreur 500 est générée avec DEBUG = False.

Si nous voulons afficher les exceptions générées, sur votre modèle (500.html), nous pourrions écrire votre propre vue 500, en saisissant l'exception et en la transmettant à votre modèle 500.

Étapes:

# Dans views.py:

import sys,traceback

def custom_500(request):
    t = loader.get_template('500.html')

    print sys.exc_info()
    type, value, tb = sys.exc_info()
    return HttpResponseServerError(t.render(Context({
        'exception_value': value,
        'value':type,
        'tb':traceback.format_exception(type, value, tb)
    },RequestContext(request))))

# Dans l'urls.py principal:

from django.conf.urls.defaults import *
handler500 = 'project.web.services.views.custom_500'

# dans le modèle (500.html):

{{ exception_value }}{{value}}{{tb}}

plus à ce sujet ici: https://docs.djangoproject.com/fr/dev/topics/http/views/#the-500-server-error-view

Vous pouvez appeler sys.exc_info () dans un gestionnaire d'exceptions personnalisé. Mais je ne recommande pas cela. Django peut vous envoyer des emails pour des exceptions.

Je sais que c'est une vieille question, mais je recommanderais de nos jours d'utiliser un service tel que Sentry pour capturez vos erreurs.

Sur Django, les étapes pour le configurer sont incroyablement simples. la documentation :

  • Installez Raven avec pip install corbeau
  • Ajoutez 'raven.contrib.django.raven_compat' à votre settings.INSTALLED_APPS .
  • Ajoutez RAVEN_CONFIG = {& dsn " ;: YOUR_SENTRY_DSN} à vos paramètres.

Ensuite, sur votre page 500 (définie dans le handler500 ), transmettez le request.sentry.id au modèle et vos utilisateurs peuvent référencer l'erreur spécifique sans afficher vos internes étant exposés.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top