-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Allow AJAX support via configuration option #1032
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 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? |
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 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.
The text was updated successfully, but these errors were encountered: