|
1 Error reporting via e-mail |
|
2 ========================== |
|
3 |
|
4 When you're running a public site you should always turn off the |
|
5 :setting:`DEBUG` setting. That will make your server run much faster, and will |
|
6 also prevent malicious users from seeing details of your application that can be |
|
7 revealed by the error pages. |
|
8 |
|
9 However, running with :setting:`DEBUG` set to ``False`` means you'll never see |
|
10 errors generated by your site -- everyone will just see your public error pages. |
|
11 You need to keep track of errors that occur in deployed sites, so Django can be |
|
12 configured to e-mail you details of those errors. |
|
13 |
|
14 Server errors |
|
15 ------------- |
|
16 |
|
17 When :setting:`DEBUG` is ``False``, Django will e-mail the users listed in the |
|
18 :setting:`ADMINS` setting whenever your code raises an unhandled exception and |
|
19 results in an internal server error (HTTP status code 500). This gives the |
|
20 administrators immediate notification of any errors. The :setting:`ADMINS` will |
|
21 get a description of the error, a complete Python traceback, and details about |
|
22 the HTTP request that caused the error. |
|
23 |
|
24 .. note:: |
|
25 |
|
26 In order to send e-mail, Django requires a few settings telling it |
|
27 how to connect to your mail server. At the very least, you'll need |
|
28 to specify :setting:`EMAIL_HOST` and possibly |
|
29 :setting:`EMAIL_HOST_USER` and :setting:`EMAIL_HOST_PASSWORD`, |
|
30 though other settings may be also required depending on your mail |
|
31 server's configuration. Consult :doc:`the Django settings |
|
32 documentation </ref/settings>` for a full list of email-related |
|
33 settings. |
|
34 |
|
35 By default, Django will send e-mail from root@localhost. However, some mail |
|
36 providers reject all e-mail from this address. To use a different sender |
|
37 address, modify the :setting:`SERVER_EMAIL` setting. |
|
38 |
|
39 To disable this behavior, just remove all entries from the :setting:`ADMINS` |
|
40 setting. |
|
41 |
|
42 404 errors |
|
43 ---------- |
|
44 |
|
45 Django can also be configured to e-mail errors about broken links (404 "page |
|
46 not found" errors). Django sends e-mails about 404 errors when: |
|
47 |
|
48 * :setting:`DEBUG` is ``False`` |
|
49 |
|
50 * :setting:`SEND_BROKEN_LINK_EMAILS` is ``True`` |
|
51 |
|
52 * Your :setting:`MIDDLEWARE_CLASSES` setting includes ``CommonMiddleware`` |
|
53 (which it does by default). |
|
54 |
|
55 If those conditions are met, Django will e-mail the users listed in the |
|
56 :setting:`MANAGERS` setting whenever your code raises a 404 and the request has |
|
57 a referer. (It doesn't bother to e-mail for 404s that don't have a referer -- |
|
58 those are usually just people typing in broken URLs or broken Web 'bots). |
|
59 |
|
60 You can tell Django to stop reporting particular 404s by tweaking the |
|
61 :setting:`IGNORABLE_404_ENDS` and :setting:`IGNORABLE_404_STARTS` settings. Both |
|
62 should be a tuple of strings. For example:: |
|
63 |
|
64 IGNORABLE_404_ENDS = ('.php', '.cgi') |
|
65 IGNORABLE_404_STARTS = ('/phpmyadmin/',) |
|
66 |
|
67 In this example, a 404 to any URL ending with ``.php`` or ``.cgi`` will *not* be |
|
68 reported. Neither will any URL starting with ``/phpmyadmin/``. |
|
69 |
|
70 The best way to disable this behavior is to set |
|
71 :setting:`SEND_BROKEN_LINK_EMAILS` to ``False``. |
|
72 |
|
73 .. seealso:: |
|
74 |
|
75 You can also set up custom error reporting by writing a custom piece of |
|
76 :ref:`exception middleware <exception-middleware>`. If you do write custom |
|
77 error handling, it's a good idea to emulate Django's built-in error handling |
|
78 and only report/log errors if :setting:`DEBUG` is ``False``. |