Alternatives for using django-debug-toolbar in Production

[ademidun]

I am running into an issue on my production Django app in Heroku where I am getting a too many connections error from postgresql.

I'm very confused by this bug as everything works fine in development/localhost but after a few requests in production my 20 Heroku connections keep getting used up. Btw, I have Sentry already but I can't use that to diagnose sql connections. Also the issue started when I started using the new Django channels and running my Procfile with Daphne.

I planned on using django-debug-toolbar to debug this so I can diagnose how to fix this issue, but the documentation said its not recommended. 1) Why is it a bad idea? 2) What are some alternatives I can use to diagnose and fix this issue in production?

[muskette]

Well the reason it's a bad idea is because your users can see data they shouldn't.
You can mitigate this by using a custom callback for displaying the toolbar.

keep the debug setting to false and add this to your settings:

def show_toolbar(request):
    return request.user and request.user.username == "yourusername"

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': 'projectname.settings.show_toolbar',

sourced from here

You would also need to ensure the debug toolbar urls are active even with debug off.
BUT this would expose the toolbar urls to ajax requests even if the end users can't see the toolbar.

[tschale]

Just a note on that: keep in mind to include the debug-toolbar middleware after the AuthenticationMiddleware, or else you won't have a user on the request ;)

[jdufresne]

BUT this would expose the toolbar urls to ajax requests even if the end users can't see the toolbar.

This was fixed in 68c4410. It is now safe to use Debug Toolbar in production so long as INTERNAL_IPS and SHOW_TOOLBAR_CALLBACK use safe values.

As this handles the original request. Closing.

[tim-schilling]

I don't think we should claim this is safe to use in production. The toolbar retains post information, unencrypted, in memory. This includes all sensitive information.

…

[jdufresne]

The toolbar retains post information, unencrypted, in memory.

This is sometimes true but no different than any other Django view or request. Django views frequently hold sensitive information in memory. So long as all public URLs are guarded in a way that displays a 404 no sensitive information is leaked.

When the SHOW_TOOLBAR_CALLBACK setting returns False, the sensitive information isn't collected in the first place.

Do you have a proof-of-concept attack for accessing this information? If so, I'll happily work towards resolving the vulnerability.

[tim-schilling]

I am not the right person to declare this insecure, but I'm not confident in this being used in production either. The only thing that I can immediately think of that could be problematic is that if other users requests get stored and can be accessed by another, then we run the risk of one user seeing the sensitive information of another. For example, if that's true, a toolbar enabled user could show the post data from a request that involved sensitive data such as a login or financial transaction. I haven't actually tested this, but if it is a problem then I suspect a fix for that is to limit the requests available in the toolbar to a specific session.