带有子域配置的django-debug-toolbar面板损坏

Question

我正在djangoproject.com网站上使用在此dev设置中配置的Django Debug Toolbar进行工作。

我在django-debug-toolbar上发现了一个问题 ，该问题在djanoproject.com的问题796中报告，但是经过一些测试，我认为这只是配置问题，我们需要帮助来解决。

以下所有句子均与本地使用的分支主机上的代码相关。

例如，如果打开http://www.djangoproject.dev:8000/ ，则Django Debug Toolbar可以很好地用于www，我可以显示该工具栏并打开SQL面板。

例如，如果我尝试打开http://docs.djangoproject.dev:8000/zh/1.11/，我可以看到工具栏，但如果尝试打开SQL面板，则会收到0: error

这是我在浏览器控制台上看到的消息：

无法加载http://www.djangoproject.dev:8000/ debug / render_panel /？store_id = 212b2bb5adc54a3a81b97b6da5547d4c＆panel_id = SQLPanel ：请求的资源上没有'Access-Control-Allow-Origin'标头。 因此，不允许访问源' http://docs.djangoproject.dev:8000 '。

如果直接打开URL，我可以看到所有数据：

http://www.djangoproject.dev:8000/ 调试 / render_panel /？store_id = 212b2bb5adc54a3a81b97b6da5547d4c＆panel_id = SQLPanel

我认为问题在于工具栏正在尝试打开www。 用于面板而不是文档。 网址，但我不知道如何更新设置以解决此问题。

您可以向我们建议用于修复此错误的代码，以及在docs.djangoproject.com的不同第三级域中使用django-debug-toolbar面板吗？

Answer 1

将解决方案答案的PR合并到djangoproject.com代码后，我想编写解决方案，以便某些用户可以从类似问题中找到解决方案。

这是来自@jezdez的问题的答案，它解释了问题：

简而言之：这是一个CORS错误，因为它尝试在不允许请求的其他子域上使用Javascript请求资源。
由debug_toolbar呈现的URL自动使用www子域的原因是因为djangoproject项目安装了django-hosts hosts_override功能，该功能会自动覆盖Django内置的url模板标记，并且能够解析Django。 URL是完全合格的URL，而不仅仅是URL路径。
现在，使用url模板标记时也会调用host_url模板标记，它将退回到使用DEFAULT_HOST设置所定义的主机（在本例中为www）。 由于我们无法轻易覆盖调试工具栏模板中对url标签的调用以传递不同的主机（例如docs），因此基本上只有一个选项：设置适当的CORS标头Access-Control-Allow-Origin以允许在docs子域下加载的页面，用于访问www子域下的资源。 我强烈建议您这样做，并且不要使URL产生混乱。 也就是说，这仅应应用于开发环境，以减少在生产中滥用的机会。
实际上，设置CORS标头就像编写一个很小的手动中间件一样简单。 无需使用像django-cors-headers这样的功能强大的应用程序。

我使用仅本地的中间件软件解决了该问题，该软件将CORS的“ Access-Control-Allow-Origin”标头设置为允许调试。

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

这是实际起作用的合并提交 。