-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Make toolbar compatible with FORCE_SCRIPT_NAME
#1970
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
Make toolbar compatible with FORCE_SCRIPT_NAME
#1970
Conversation
Previously, if a project used the `FORCE_SCRIPT_NAME` setting (common when hosting a Django application on a subdirectory path via a reverse proxy), the `django.urls.resolve()` call would always raise `Resolver404` in the middleware. As a result, `is_toolbar_request()` always returned False. This caused internal toolbar URLs to be inspected, and also indirectly led to a request loop when refreshing the history panel. In most cases (if `FORCE_SCRIPT_NAME` is unset), `get_script_prefix()` will return "/" and the `replace()` will be a no-op.
8f39e06
to
e628c91
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you try using request.path_info instead of request.path? The former should do the right thing if Django isn't mounted at '/' without having to use the script prefix explicitly. (I haven't tested it myself.)
Oh, that does work and is a lot cleaner! Thanks for the suggestion. I can make that change, but what would you like to do with the existing tests that just override @override_settings(ROOT_URLCONF="tests.urls_invalid")
def test_is_toolbar_request_override_request_urlconf(self):
"""Test cases when the toolbar URL is configured on the request."""
self.request.path = "/__debug__/render_panel/"
self.assertFalse(self.toolbar.is_toolbar_request(self.request)) I can also add matching request.path_info overrides to each of these, or I suppose they could be outright replaced with request.path_info overrides for all tests except mine which is explicitly testing the behavior when they differ. |
@dmartin could we switch them with a |
Maintains support for `SCRIPT_NAME` without manually calling `get_script_prefix()`. Tests that involved manually setting the `path` attribute of a request have been reworked to use a `RequestFactory` so that the `path` and `path_info` attributes are both set appropriately.
f1e0929
to
fb354f1
Compare
I made those changes, though I didn't rework every test to use a RequestFactory to keep the scope of the PR under control, only the tests that were manually setting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with this change.
It definitely highlights a problem we have in the test suite where we manipulate a request after initializing the toolbar. It's possible we may run into a bug where the the toolbar does something slightly differently because of this. However, if that were the case, I would have expected it to crop up before now.
Thank you! |
Description
Previously, if a project used the
FORCE_SCRIPT_NAME
setting (such as when hosting a Django application under a subdirectory path via a reverse proxy),is_toolbar_request()
would always return False.This is because
request.resolver_match
is not yet available in the middleware context, sodjango.urls.resolve()
is called instead.resolve()
then raisedResolver404
, because it does not takeFORCE_SCRIPT_NAME
into account.This caused internal toolbar URLs to be inspected, leading to a request loop when refreshing the history panel.
This PR makes calls to
django.urls.resolve()
takerequest.path_info
rather thanrequest.path
. This effectively strips the request's leadingSCRIPT_NAME
if one is present.Fixes #1961
Checklist:
docs/changes.rst
.