SHOW_TOOLBAR_CALLBACK change in django-debug-toolbar 1.8 breaks existing code and it is not documented

[glasslion]

In django-debug-toolbar 1.7 and below, the SHOW_TOOLBAR_CALLBACK callback is used to check both whether a request to debug-toolbar views should be authorized and whether a request is ajax.

In django-debug-toolbar 1.8, the ajax check is moved into the middleware, and it raises a 404 if a request can not pass the SHOW_TOOLBAR_CALLBACK check.

So a callback written for django-debug-toolbar<=1.7 will broken debug-toolbar 1.8's ajax request. :-(

Debug-toolbar's own doc still indicates that the callback should check if the request is AJAX, it's confusing：

The default checks are that DEBUG must be set to True, the IP of the request must be in INTERNAL_IPS, and the request must not be an AJAX request.

Because those 404s do not have explicit error messages, it is even harder to find the root cause.

[matthiask]

Cc @jdufresne you might want to take a look at this? Does the PR make sense to you?

[awbacker]

In my case I don't want to do the internal_ips check since we work in ways where thats really not possible. I had overridden the callback to check debug + !is_ajax(), and that was broken now (not sure why). This changed fixed it for me:

        def show_toolbar_handler(request):
-            return settings.DEBUG and not request.is_ajax()
+            return settings.DEBUG

As for changes to message, I would stick with the 404 from the resource, however... The calling panel obviously can render html, so it could:

• detect that you are using a custom callback and ask you to check that
• say 404 but give a list of possible reasons

Just a thought. This was quite frustrating, as @glasslion says. Since there is nothing that indicates the possible causes of the error and if you copy the failing url into your browser directly it works! So somehow the

[jdufresne]

and that was broken now (not sure why)

The behavior changed so that SHOW_TOOLBAR_CALLBACK could be reused to guard against unauthorized access of panel views that are requested with AJAX. So the AJAX check is not always applicable. The details of this are outline in PR #926.

It was my mistake not documenting this breaking change, but the net effect is that panel views now check access is allowed to avoid leaking private data, which I think should remain.

I think modifying the documentation to alert users to the breaking changes is the best way to handle it without reintroducing unauthorized access of panel views.