Broken django-debug-toolbar panels with sub domains configuration

Question

I'm working on djangoproject.com website with Django Debug Toolbar configured in this dev settings .

I founded an issue with django-debug-toolbar that I reported in the issue #796 of djanoproject.com but after some test I think it's only a configuration problem and we need help to solve it.

All the below sentence are related with the code on branch master used locally.

Django Debug Toolbar works well for www , for example, if I open http://www.djangoproject.dev:8000/ I can show the toolbar and open the SQL panel.

If I try to open for example http://docs.djangoproject.dev:8000/en/1.11/ I can see the toolbar but I got 0: error if I try to open SQL panel

This is the message I saw on browser console:

Failed to load http://www.djangoproject.dev:8000/ debug /render_panel/?store_id=212b2bb5adc54a3a81b97b6da5547d4c&panel_id=SQLPanel : No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin ' http://docs.djangoproject.dev:8000 ' is therefore not allowed access.

I can see all the data if I open directly the url:

http://www.djangoproject.dev:8000/ debug /render_panel/?store_id=212b2bb5adc54a3a81b97b6da5547d4c&panel_id=SQLPanel

I think the problem is that the toolbar is trying to open a www. for the panel instead of a docs. url but I don't know how to update the settings to fix this.

Can you suggest to us the code to fix this bug and to use django-debug-toolbar panels with in different third-level domains as for docs.djangoproject.com ?

Answer 1

After my PR with the answer of this solution was merged into the djangoproject.com code I want to write the solution so some user can find solution fro similar question.

This is the answer from @jezdez the issue which explain the problem:

In short: this is a CORS error since it tries to request a resource with Javascript on a different subdomain that isn't allowed to be requested.
The reason why the URL that is rendered by debug_toolbar uses the www subdomain automatically is because the djangoproject project has the django-hosts hosts_override feature installed, which automatically overrides the Django-built-in url template tag witht he one that is capable of resolving Django URLs as a fully qualified URLs and not only as URL paths.
The host_url template tag which is by now also called when the url template tag is used, will fall back to using the host as defined by the DEFAULT_HOST setting, which in our case is www. Since we can't easily override the call to the url tag in the debug toolbar template to pass in a different host (eg docs) there is basically only one other option: set the appropriate CORS header Access-Control-Allow-Origin to allow a page loaded under the docs subdomain to access a resource under the www subdomain. I would strongly suggest to do that and not mess with the URL generation. That said, this is something that should only be applied to the development environment, to reduce the chance for abuse in production.
Actually setting the CORS header is as simple as writing a very small middleware that does it manually. No need to use a full-blown app like django-cors-headers.

I solved the problem with a local-only middelware which set the CORS 'Access-Control-Allow-Origin' header to allow the debug.

class CORSMiddleware(object):
    """
    Set the CORS 'Access-Control-Allow-Origin' header to allow the debug
    toolbar to work on the docs domain.
    """
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        response['Access-Control-Allow-Origin'] = '*'
        return response

Here is the merged commit that actually is working.