CORS required as of v3.0

[WhyNotHugo]

#1283 introduced an undocumented change: it is not required to set up CORS on the domain that serves static files (given that it's documented, I'd say it's more of a regression):

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://static.myapp.localhost:8000/static/debug_toolbar/js/toolbar.js. (Reason: CORS request did not succeed).

I understand that ES6 modules are "the new thing", however, it took me quite a while to figure out why debug toolbar was no longer showing up. This new requirement is not documented anywhere, nor is it in the setup instructions (as such, setting up a new project also fails, unless you serve static files using Django).

Is this change intentional? Is there any way to avoid having to set up CORS on the staticfiles domain? If it's intentional, can it please be documented properly?

[matthiask]

Thanks for the report!

@jdufresne This behavior change probably wasn't intentional? I haven't started looking for a solution for this yet; maybe you already have an idea?

[jdufresne]

Thanks for reporting this.

Requiring CORS configuration was not intentional, but after researching this I think it will be required for using JS modules outside a local development environment.

JavaScript modules are offer some significant advantages so even though it was not intentional, I think we should keep it and now document CORS rather than revert the change. If there is agreement here, I don't mind drafting these doc changes in a PR.

[jdufresne]

I opened PR #1399 to document the issue and how to resolve it. All feedback and suggestions are welcome. Cheers.

[WhyNotHugo]

it will be required for using JS modules outside a local development environment.

What do you mean by this statement? It's also required in a local development environment (I'm only actually using the toolbar for development).

[jdufresne]

All I meant by this is to describe the typical (but not only) use case of the Django development server that serves all application responses and static files from localhost:8000.

[kukosk]

I stumbled upon this issue just now as I was updating pip packages, and find it a bit inconvenient. I think a lot of developers use a typical nginx-gunicorn setup also for their development environment. Over the time, on a bigger project, I found quite a few notable differences with my production server when I was using runserver. And so I decided to set it up exactly the same as in production. I think I'll have to downgrade to v2.2 for now, but it would be awesome to see this resolved one day.

[jdufresne]

@kukosk Rather than downgrading, why not add the single line to your NGINX configuration as described in PR #1399? It is a one line change and then doesn't need a 2nd thought.

[kukosk]

Thank you for the response @jdufresne. I initially wanted to make that change in my nginx config, as I also thought it will be a one-liner and that I'll only add it for that single file, but it turned out to be pretty complicated in nginx as seen here.

I was thinking, maybe even adding a proxy workaround for that file would be great! Just dynamically appending a url() that would contain the proxy to the .js file would be enough. django-debug-toolbar is usually used only for development, so I think it wouldn't be that bad.

[jdufresne]

but it turned out to be pretty complicated in nginx as seen here.

Hmmm. In my testing, all that extra stuff was unnecessary for the purposes of getting toolbar's JS module to load. Did you try the single line change?

I changed my existing config from

location /static/ {
    rewrite ^/static/(.*) /$1 break;
    proxy_pass http://127.0.0.1:3000;
}

To (one new line):

location /static/ {
    rewrite ^/static/(.*) /$1 break;
    proxy_pass http://127.0.0.1:3000;
    add_header Access-Control-Allow-Origin http://localhost:8000;
}

Then restarted NGINX and it worked. See the screenshot below.

[kukosk]

Wow @jdufresne, thank you very much! It totally works now, I thought it'll be more complicated, and didn't see that single line change mentioned in the PR 👍 . I made the nginx config a bit more strict, to prevent adding the CORS header to files not related to the toolbar:

# FOR DEVELOPMENT ONLY
location /debug_toolbar/js/ {
  add_header Access-Control-Allow-Origin "*" always;
}

The only issue I found is when I open the 'history' tab, and click refresh. The request fails with HTTP 400. But that doesn't seem to be anyhow related to the original problem. The content of the response is 'Form errors', so I guess that's some other issue probably not caused by my configuration.

Thank you again, and have a great day!

[jdufresne]

Thanks for following up and testing the suggestion.

and didn't see that single line change mentioned in the PR

If you have any suggestions at all that would make the wording easy to follow, don't hesitate to let me know. Cheers.