Closed jgbishop closed 3 years ago
Can you provide more details about your use case? Why do you want to render the panels in a AJAX request? Is your AJAX request returning full HTML documents such that injecting the HTML makes sense? Do you have details about what this AJAX request is doing and what you want Django debug toolbar to do with it? Do you have a minimal example project to demonstrate this use case?
Instead of adding a new option, I'd like to better understand the use case to determine if we can make the middleware work securely for you.
I'm actually not interested in rendering the panels at all in an AJAX use case; I'm more interested in accessing the data the toolbar would normally gather. Primarily, I'm interested in what SQL queries are being generated by my AJAX routines (e.g. am I missing the necessary select_related
or prefetch_related
calls?).
As far as I can tell, no data is ever gathered for AJAX requests because the data gathering step seems to be tightly coupled to actually rendering the toolbar. The django-debug-toolbar-request-history panel (a third-party panel for DDT) works around this limitation by monkey-patching your monkey-patches. In my own attempts at creating a custom panel for DDT, I don't seem to get any data for AJAX calls due to the code I mentioned in my original report above. As soon I as I disable those lines, I get data.
Perhaps the data gathering and toolbar rendering need to be decoupled? Or perhaps I'm missing something obvious?
Perhaps the data gathering and toolbar rendering need to be decoupled? Or perhaps I'm missing something obvious?
I'd really like to see this. I'm interested in building a real time monitoring webapp (for devs locally) that shows a history of requests and for each request you can view the panel content for each registered panel.
I think keeping a history of toolbars (for all requests) up to a configurable max would allow my idea to work. The implementation of django-debug-toolbar-request-history
is difficult due to the lack of this history feature, this package has to monkey patch django debug toolbar to get it working.
If debug_toolbar exposes this history then I think I could write a small package that built a realtime web UI around all of the existing panels which would make debug_toolbar extremely useful for people developing django restframework apps
For reference, the Pyramid debug toolbar logs data for all requests, and is accessible at its own URL. It doesn’t matter if your requests return JSON, CSV or a PDF, you can always open the toolbar URL in your browser and see recent requests there.
(see also #999)
👍
FWIW https://github.com/recamshak/django-debug-panel works for this use case!
I am not using chrome any more; I think I last used django-debug-panel with a Django 1.11 project.
with Ajax being incredibly useful and common, I don't understand why this isn't a thing. Coming from Laraval (PHP) their DebugBar captured Ajax request and was super helpful. I'll also echo what @jgbishop said, this is especially helpful for SQL queries.
Agree, I'm trying to set up django debug panel with django 3.0 and it's not working at all...
Because the request.is_ajax() method is deprecated, would it be useful to have SQL output or whatever in your terminal output?
@matthiask I guess this issue can closed since 3.X is out
@MRigal Thanks! Yes that's right.
The
process_request
routine within theDebugToolbarMiddleware
class (in middleware.py) disables rendering the toolbar for AJAX requests:This logic prevents third party panels from accessing data on AJAX requests and responses (e.g. the Django Debug Panel doesn't work properly with this logic in place). I propose a configuration option to allow users to turn this behavior back on. It would be fine for the option to be disabled by default, but I'm willing to put up with any performance / memory hits for the perk of being able to view AJAX data.
In investigating further, I note that this change was implemented as a part of #926 (which fixed #834). As a developer, I'm willing to risk the potential security weakness in my setup, as I only run DDT in local setups or on dedicated sandbox systems.