django-debug-toolbar: SHOW_TOOLBAR_CALLBACK no longer supports lambda

in my setup i always have seperate dev settings and in those settings i enable debug toolbar for all requests. i’ve always done that with the following config

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': lambda request: True,
}

after updating my virtualenv this morning i started getting errors that i’ve tracked down to trying to run rsplit on func_path

line 45 of debu_toolbar/middleware.py:

    mod_path, func_name = func_path.rsplit('.', 1)

it looks like the meaning of SHOW_TOOLBAR_CALLBACK may have changed to require a string and not support a callable. if that’s the case i’m not sure what the solution would be. i’d rather not have to define a function somewhere and point this at it just to return true. i’d prefer if SHOW_TOOLBAR_CALLBACK supported being presented a callable.

About this issue

Original URL
State: closed
Created 10 years ago
Comments: 22 (12 by maintainers)

Commits related to this issue

Restore support for callables in SHOW_TOOLBAR_CALLBACK. Fix #523. — committed to ryneeverett/django-debug-toolbar by aaugustin 10 years ago

Most upvoted comments

All Django settings have primitive values, to avoid the temptation to import stuff in settings. The Debug Toolbar follows this philosophy. I’m sorry that it makes your use case marginally less practical, but I still think it’s a good trade-off for the community at large.

I would suggest the following (untested) code:

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': "%s.true" % __name__,
}

def true(request):
    return True

aaugustin on Jan 8, 2014

I dont think developers being ignorant is a good reason to remove simplicity 😃

dcramer on Nov 1, 2014

@Rabia23 you could define a function rather than a lambda:

def show_toolbar(request):
    from django.conf import settings
    return settings.DEBUG

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': show_toolbar,
}

Alternatively since DEBUG shouldn’t change, you could use a ternary operation.

DEBUG_TOOLBAR_CONFIG = {
    'SHOW_TOOLBAR_CALLBACK': (lambda request: True) if DEBUG else (lambda request: False),
}

tim-schilling on Jan 20, 2022

Spend more than an hour on this until I finally got it working on my dev server. This is so frustrating! It is impossible to save idiots from making stupid mistakes. They will still find many workaround and do stupid security shit. Default security measures just makes this wonderful tool so complicated and frustrating to work with. I just want to plug and play with it. Will take over security stuff my self as I am a developer and that’s my job.

All of this is completely out of the scope of The Zen of Python: https://www.python.org/dev/peps/pep-0020/

There should be no additional options at all for displaying toolbar or not. If you have it in your installed apps it’s displayed if not, it’s not displayed. That’s it. Leave everything else for developers to decide.

Anyway, thanks for running this amazing tool! I am a huge fan of it, except for these stupid security measures.

Simanas on Jul 2, 2015

+1 on restoring callables

The “Django way” is not always the right way, and this turns a simple problem into a complex problem in many situations.

dcramer on Nov 1, 2014

Given that the exact same thing can be done as demonstrated above, was there a need to remove the old behaviour? Just feels like it results in a slightly more ugly settings file for my local/dev instances.

My opinion for the best option would be to default to 'debug_toolbar.middleware.show_toolbar' by default as the recommended option in the documentation, with iscallable being used for those of us who actually want it to be a function/lambda.

It’s a debug toolbar, I’d hope that anyone installing it would recognise the fact that it can show a lot of sensitive information and that we don’t need protecting in this way.

tomkins on Jan 14, 2014