Develop Reference

Django: Avoid showing error details in production

I am trying to make sure that my site is properly protected from showing the details of the error in production.
I've been struggling with this for a while, as at beginning I understood that in order to avoid Django from showing the error (module, line of code, etc.) all that was needed was changing DEBUG from True to False in settings.py.
However, I realized that Django was still showing error details, so investigating a bit more and I came to know that the following was also needed:
TEMPLATE_DEBUG = DEBUG in settings.py
404.html and 500.htmlinside the templates folder
Is there anything else needed to make sure that the user does not get those messages?
And how does Django deal with the other kind of errors, like 400? I saw here that there are handlers for 400 and 403, but I do not understand it and I don't know if they are needed at all for a basic using case.

If DEBUG is False, Django doesn't show error details to the user. If it did in your case, the most likely explanations are either that it's not using the settings.py file you think it's using (in which case you should check the Python path, the directory from which you run manage.py, and the value of DJANGO_SETTINGS_MODULE), or that you did not restart Gunicorn/uWSGI/Apache after you made the change to settings.py (Django does not restart itself automatically in production like it does in development).
As for 400 and 403, just leave the Django defaults. If Django receives a bad request (unlikely in production, because this will usually be caught by Apache or nginx), it will call bad_request() which will just show a "400 bad request" to the user. Likewise for other errors.

Sentry logged exception without additional data

Sentry 6.4.4
Python raven 5.0.0
Integration with Django 1.7.0.
When I try to store 500 error (automation raven handling), I get in Sentry empty event, without any additional information.
It stored only exception name and time.
But this should be request information, additional info, etc.
I checked my project configuration with http://getsentry.com - in this site all works fine, so problem with my Sentry installation.
But I can't find any information what I should set up to store this data, it seems like this should works from box. But not in my case.

Issue was with cache.
Solution is set projects settings:
CACHES = None

How to properly deal with errors on live django site?

Let's say I have a try and catch and there is an exception ... What is the proper way to deal with those exceptions/errors on a live production (django) site?
So I have
try:
create_response = wepay.call('/account/create',
{'name': name, 'description': desc})
self.wepay_account_id = create_response['account_id']
self.save()
except WePay.WePayError as e:
..... (what do I put here?

You can set up e-mail error reporting through Django: https://docs.djangoproject.com/en/dev/howto/error-reporting/
Or you can use a service like Rollbar (has a free account) to track error occurances.
Or you could use self-hosted Greylog (like suggested in comments), here's a good guide for django: http://www.caktusgroup.com/blog/2013/09/18/central-logging-django-graylog2-and-graypy/

Respond with (optionally a redirect to) a appropriate page explaining the problem to the user and if possible, provide a solution. Serving a 500 to your users in production is something you want to avoid, so catching the exception is a good idea.
So:
except WePay.WePayError as e:
return render_to_response('wepay_error_page.html')
or:
except WePay.WePayError as e:
return HttpResponseRedirect('/errors/wepay/') # Note: better use urlresolvers
(note this particular code will only work if it's in a view)
Then (optionally), make sure you get a copy of the error, by for example sending yourself an email.
A suggestion for this particular case (if I interpret the code succesfully) may be to notify yourself, and repond with a page explaining to the user their payment went wrong. Tell them this might occur because of their actions (maybe they cancelled their payment), and provide contact details for when users think it was not their fault.
Django by default mails (when mail is properly configured) all 500 errors to settings.ADMINS, but these only occur on uncaught exceptions, so in this particular question services like Rollbar or a central logging solution will only work if you re-raise the exception (will result in a 500) or send the error to one of these manually in the catch block.

I would recommend the above solution of redirecting over to a page that explains WePay error, combined with using django-wepay app available on pypi that features logging of all errors, and optionally all calls.

django development server quitting

When I attempt to access particular pages of my application on the django development server, the server suddenly quits with no error message, leaving the browser with a "Error 324 (net::ERR_EMPTY_RESPONSE)"
What kind of thing could I have done in the code that would cause the development server to suddenly quit with no error messages?
The GET request that triggers the server to quit is not logged. For example, after starting the server and attempting a GET of one of the problem pages, my command line looks like this:
(mysite)01:25 PM benjamin ~/projects/mysite $ runserver
Validating models...
0 errors found
Django version 1.3.1, using settings 'mysite.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
(mysite)01:28 PM benjamin ~/projects/mysite $
I'm running django 1.3.3 in a virtualenv using Python 2.6

I found this because I was encountering a similar problem. It turned out I was running out of memory. Figured I would mention it on the off chance that it helps someone.

The bus error can happen when you're trying to extend a template with another template that has the same filename and relative path.
Example
Let's say you want to use your own poll.html template for the voting app, but to reuse as much as possible, you extend from the original poll.html:
<!-- myapp/templates/voting/poll.html -->
{% extends 'voting/poll.html' %}
<!-- Trying to extend from 'voting/templates/voting/poll.html' -->
...
This will give you the bus error, because the template is extending "itself", even though that's not what you're trying to do.
Your own voting/poll.html is shadowing the original poll.html from the voting app, which will never be found
myproject/myapp/templates/voting/poll.html
myproject/voting/templates/voting/poll.html <-- you cannot extend from this
I haven't found a general solution to this, but I ran into the problem trying to customize the admin app's index.html and for that there is a solution (See below).
Customizing the "admin" app
I got the "bus error" when trying to customize the index.html in the admin app, and extending from the original admin/index.html. The solution to that specific problem is described here: How to override and extend basic Django admin templates? – you name your own admin/index.html something else, in order to extend from the original admin/index.html

Web2py ticket invalid links

I started playing around with web2py the other day for a new project. I really like the structure and the whole concept which feels like a breath of fresh air after spending a few years with PHP frameworks.
The only thing (currently) that is bothering me is the ticketing system. Each time I make a misstake a page with a link to a ticket is presented. I guess I could live with that if the link worked. It currently points to an admin page with http as protocol instead of https. I've done a bit of reading and the forced https for admin seems to be a security measure, but this makes debugging a pain.
Whats the standard solution here? Alter the error page, allow http for admin och use logs for debugging?
Best regards
Fredrik

I was in the same boat as you, I did not like the default mechanism. Luckily, customized exception handling with web2py is very straightforward. Take a look at routes.py in the root of your web2py directory. I've added the following to mine:
routes_onerror = [('application_name/*','/application_name/error/index')]
This routes any exceptions to my error handler controller (application_name/controllers/error.py) in which I defined my def index as:
def index():
if request.vars.code == '400':
return(dict(app=request.application,
ticket=None,
traceback="A 400 error was raised, this is controller/method path not found",
code=None,
layer=None,
wasEmailed=False))
elif request.vars.code == '404':
return(dict(app=request.application,
ticket=None,
traceback="A 404 error was raised, this is bad.",
code=None,
layer=None,
wasEmailed=False))
else:
fH = file('applications/%s/errors/%s' % (request.application,request.vars.ticket.split("/")[1]))
e = cPickle.load(fH)
fH.close()
__sendEmail(request.application,e['layer'],e['traceback'],e['code'])
return(dict(app=request.application,
ticket=request.vars.ticket,
traceback=e['traceback'],
code=e['code'],
layer=e['layer'],
wasEmailed=True))
As you can see for non-400 and 404 errors, I'm emailing the traceback to myself and then invoking the corresponding views/error/index.html. In production, this view gives a generic "I'm sorry an error has occurred, developers have been emailed". On my development server, it displays the formatted traceback.

Normally, I just use http://127.0.0.1/ (if you are local or over ssh) or edit/navigate using https://...
So, you will logon the admin app the first time, but always will the show the tickets after.