Django n'envoie pas de courrier électronique aux administrateurs
Selon documentation , si DEBUG est défini sur False et que quelque chose est fourni avec le paramètre ADMINS, Django enverra un courrier électronique chaque fois que le code génère un code d'état 500. Les paramètres de messagerie sont correctement remplis (car je peux utiliser send_mail amende), mais chaque fois que je mets intentionnellement du code erroné, je reçois mon modèle 500.html, mais aucun message d'erreur n'est envoyé. Qu'est-ce qui pourrait empêcher Django de faire cela?
Dans mon cas, la cause était manquante SERVER_EMAIL paramètre.
La valeur par défaut de SERVER_EMAIL est _root@localhost_. Mais beaucoup de serveurs de messagerie, y compris mon fournisseur de messagerie, n'acceptent pas les courriels provenant d'adresses aussi suspectes. Ils lâchent les emails en silence.
Le fait de changer l'adresse e-mail de l'expéditeur en _[email protected]_ a résolu le problème. Dans _settings.py_:
_SERVER_EMAIL = '[email protected]'
_Une autre possibilité d'erreur est un problème avec votre paramètre ADMINS. Le paramètre suivant entraîne l'échec de l'envoi de courrier vers les administrateurs:
ADMINS = (
('your name', '[email protected]')
)
Qu'est-ce qui ne va pas avec ça? Bien ADMINS doit être un tuple de n-uplets, donc ce qui précède doit être formaté comme
ADMINS = (
('your name', '[email protected]'),
)
Notez la virgule de fin. Sans la virgule défaillante, l'adresse "à" de l'e-mail sera mal formatée (puis probablement ignorée en silence par votre serveur SMTP).
J'ai eu la même situation. J'ai créé un nouveau projet et une nouvelle application et cela a fonctionné. Je savais donc que c'était mon code. Je l'ai retrouvé dans le dictionnaire LOGGING dans settings.py. Il y a quelques semaines, j'avais apporté des modifications à l'enregistrement avec Sentry, mais pour une raison quelconque, l'erreur vient de commencer aujourd'hui. Je suis revenu à l'original et je l'ai fait fonctionner:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'mail_admins': {
'level': 'ERROR',
'class': 'Django.utils.log.AdminEmailHandler'
}
},
'loggers': {
'Django.request': {
'handlers': ['mail_admins'],
'level': 'ERROR',
'propagate': True,
},
}
}
Ensuite, j'ai apporté quelques modifications lentement et je l’ai fait fonctionner avec Sentry et en envoyant également un courrier électronique à ADMINS.
De plus, la configuration LOGGING est fusionnée avec DEFAULT_LOGGING par défaut. Il est donc utile de consulter le code source de Django.utils.log.DEFAULT_LOGGING pour comprendre ce qui pourrait avoir une incidence sur votre situation particulière.
Assurez-vous que votre EMAIL_Host et votre EMAIL_PORT sont configurés directement dans settings.py (ils font référence à votre serveur SMTP). Cela peut supposer que vous avez un serveur SMTP s'exécutant sur localhost.
Pour tester cela localement, exécutez le serveur SMTP de test intégré de Python:
python -m smtpd -n -c DebuggingServer localhost:1025
Puis définissez ces valeurs dans votre settings.py
EMAIL_Host='localhost'
EMAIL_PORT=1025
Déclenchez une erreur 500 et le courrier électronique devrait apparaître dans la fenêtre du terminal python smtpd.
Mon fournisseur d'hébergement Web, Webfaction, autorise uniquement l'envoi d'e-mails à partir d'un e-mail créé explicitement dans le panneau de l'administrateur. En créer un a résolu le problème.
Une autre chose à noter ici est que les paramètres handler500 peuvent contourner le mécanisme qui envoie des erreurs sur un 500 si la réponse de la vue n’a pas un code de statut de 500 . Si vous avez un ensemble handler500, alors dans cette vue, répondez avec quelque chose comme ça.
t = loader.get_template('500.html')
response = HttpResponseServerError(
t.render(RequestContext(request, {'custom_context_var':
'IT BROKE OMG FIRE EVERYONE'})))
response.status_code = 500
return response
Désolé si c'est trop naïf, mais dans mon cas, les courriels ont été envoyés mais allaient directement dans le dossier SPAM. Avant d’essayer des choses plus compliquées, vérifiez d’abord votre dossier SPAM.
Assurez-vous d'avoir DEBUG = False
Essaye ça
# ./manage Shell
>>> from Django.core.mail import send_mail
>>> send_mail('Subject here', 'Here is the message.', '[email protected]',['[email protected]'], fail_silently=False)
Avec un [email protected] auquel vous recevez réellement un courrier électronique.
... et puis il y a l'erreur facepalm, lorsque vous avez utilisé cela en développement pour empêcher les e-mails de sortir, puis copiez accidentellement le paramètre dans la production:
# Print emails to console
EMAIL_BACKEND = 'Django.core.mail.backends.console.EmailBackend'
(Bien sûr, vous ne les voyez pas être imprimées sur la console lorsque vous utilisez un serveur wsgi). Supprimer le réglage de la production a corrigé cela pour moi.
Je viens d'avoir le même problème après la mise à niveau vers Django 2.1 à partir de Django 1.11. Apparemment, les sections ADMINS dans settings.py ont changé. Il faut une liste de tuples maintenant, plutôt que le vieux Tuple de tuples. Cela a corrigé pour moi.
##### old #####
ADMINS = (
("Your Name", "[email protected]")
)
##### new #####
ADMINS = [
("Your Name", "[email protected]")
]
Re: https://docs.djangoproject.com/en/2.1/ref/settings/#admins
Si, pour une raison quelconque, vous définissez DEBUG_PROPAGATE_EXCEPTIONS sur True (c'est False par défaut), le courrier électronique à l'administrateur ne fonctionnera pas.
Bien que cela fasse un moment, voici ma réponse pour que d’autres personnes puissent en bénéficier à l’avenir.
Dans mon cas, ce qui empêchait l'envoi d'e-mails à la liste ADMINS, lorsqu'une erreur se produisait, était un paramètre spécifique à l'application. J'utilisais Django-piston, qui fournit les attributs de réglage PISTON_EMAIL_ERRORS et PISTON_DISPLAY_ERRORS. En définissant ces paramètres en conséquence, le serveur d’application a été informé de la nécessité d’invoquer mon courrier par courrier électronique chaque fois que piston se bloquerait.
Ce problème m'a suffisamment énervé pour motiver un poste. Je présente ici les étapes que j'ai suivies pour résoudre ce problème (en raccourcissant une longue histoire):
- Echec de la configuration de la page de test (en renommant test_template.html)
- Vérifiez les validations d'e-mails via les vues de la page de test en production à l'aide de send_mail ('Hello', 'hello, world', '[email protected]', [('Nom', '[email protected]'),], fail_silently = False) où SERVER_EMAIL = '[email protected]' et ADMINS = [('Nom', '[email protected]'),] dans Django paramètres. Dans mon cas, j'ai reçu l'email 'hello world', mais pas l'email Django admin (qui était pénible).
- Configurez un simple enregistreur personnalisé pour créer un rapport dans un fichier sur le serveur:
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'errors_file': {
'level': 'ERROR',
'class': 'logging.FileHandler',
'filename': 'logs/debug.log',
},
},
'loggers': {
'Django': {
'handlers': ['errors_file'],
'level': 'ERROR',
'propagate': True,
},
},
}
Dans mon cas, la navigation vers la page de test ne générait pas de sortie dans le fichier debug.log sous le répertoire logs du répertoire racine de mon projet. Cela indique que l'enregistreur n'a pas réussi à atteindre un "niveau" ERROR.
- Rétrogradez le seuil de rapport pour le consignateur personnalisé d'ERROR à DEBUG. Maintenant, naviguer vers la page de test devrait fournir quelques détails. L'inspection de ce détail a révélé dans mon cas que la page 500 par défaut avait été redirigée (par inadvertance) vers un autre fichier modèle appelé 500.html. Ce fichier de modèle utilisait une variable pour la mise en cache et, comme le modèle n'était pas appelé via une vue rendant la variable disponible dans le contexte, l'appel du cache a échoué avec une référence de clé manquante. Renommer 500.html a résolu mon problème.
Pour ce que ça vaut la peine d’avoir ce problème, aucune de ces suggestions n’a fonctionné pour moi. Il s’est avéré que mon problème était que SERVER_EMAIL était défini sur une adresse non reconnue par le serveur (Webfaction). Si ce site était hébergé sur Webfaction (comme mes autres sites), ce ne serait pas un problème, mais comme c'était sur un serveur différent, les serveurs Webfaction ne vérifient pas seulement l'authentification de l'email envoyé, mais aussi la valeur From: également.
Dans mon cas, c'est le include_html dans mail_admins.
Lorsque je règle include_html sur True, le serveur de messagerie refuse d'envoyer mon courrier électronique car il considère que mes courriers électroniques sont du spam.
Tout fonctionne très bien lorsque je règle include_html sur False.
Bien que cela ne soit probablement pas idéal, j’ai constaté que l’utilisation de Gmail en tant qu’hôte SMTP fonctionnait parfaitement. Il existe un guide utile sur nathanostgard.com .
N'hésitez pas à publier vos sections settings.py pertinentes (y compris EMAIL_ *, SERVER_EMAIL, ADMINS (prenez simplement votre courrier électronique réel), MANAGERS et DEBUG) si vous voulez des yeux supplémentaires pour vérifier les fautes de frappe!
Si vous utilisez ou souhaitez utiliser SendGrid, utilisez les paramètres ci-dessous en production.
Installer le paquet
pip install sendgrid-Django
Ajoutez ces paramètres dans settings.py (production)
DEBUG = False
EMAIL_BACKEND = "sendgrid_backend.SendgridBackend"
SENDGRID_API_KEY = "That you generate in sendgrid account"
ADMINS = (
("Your Name", "[email protected]")
)
Et encore une autre chose qui peut mal se passer (je vais juste l’ajouter à la liste, pour les personnes qui se retrouvent ici malgré toutes les bonnes réponses ci-dessus):
Notre configuration Django utilisait SendGrid en tant qu'hôte smtp et une seule adresse électronique d'administrateur définie dans les paramètres Django. Cela a bien fonctionné pendant un certain temps, mais à un moment donné, les courriers ont cessé d’arriver.
En fin de compte, l'adresse de messagerie s'est retrouvée dans la liste 'Renvoyée' de SendGrid pour une raison inconnue, ce qui a entraîné la suppression ininterrompue des courriers électroniques à cette adresse. Le fait de supprimer l’adresse de cette liste et de la mettre en liste blanche a résolu le problème.
Les informations ci-dessous sont données dans https://docs.djangoproject.com/fr/2.1/howto/error-reporting/#email-reports
EMAIL_Host = "email Host"
EMAIL_Host_USER = "Email username"
EMAIL_Host_PASSWORD = "Email Password"
DEBUG = False
ADMINS = (
("Your Name", "[email protected]")
)
Pour envoyer un courrier électronique, Django a besoin de quelques paramètres lui expliquant comment .___. pour vous connecter à votre serveur de messagerie. À tout le moins, vous aurez besoin de spécifiez EMAIL_Host et éventuellement EMAIL_Host_USER et EMAIL_Host_PASSWORD, bien que d'autres paramètres puissent également être requis en fonction de la configuration de votre serveur de messagerie. Consultez le Django documentation sur les paramètres pour une liste complète des paramètres liés au courrier électronique.