Refused to get unsafe header "djdt-store-id"

[xiongchiamiov]

We're getting instances of this error in the javascript console while using the toolbar in local development.

This stems from a CORS issue where only certain headers are only allowed to be accessed unless whitelisted. In 9973872 this code was added:

    update_on_ajax() {
        const sidebar_url =
            document.getElementById("djDebug").dataset.sidebarUrl;
        const slowjax = debounce(ajax, 200);

        const origOpen = XMLHttpRequest.prototype.open;
        XMLHttpRequest.prototype.open = function () {
            this.addEventListener("load", function () {
                let store_id = this.getResponseHeader("djdt-store-id");
                if (store_id !== null) {
                    store_id = encodeURIComponent(store_id);
                    const dest = `${sidebar_url}?store_id=${store_id}`;
                    slowjax(dest).then(function (data) {
                        replaceToolbarState(store_id, data);
                    });
                }
            });
            origOpen.apply(this, arguments);
        };
    },

Since it's patching XMLHttpRequest.open to attempt to examine all ajax requests, this gets triggered when making requests to things that don't allow djdt-store-id access (and shouldn't, because they're owned by third parties and don't know anything about this tool). This doesn't appear to functionally break anything, but it adds confusing error messages.

I think the answer is to squash the error in this line: let store_id = this.getResponseHeader("djdt-store-id");. It's not clear to me how to do this, though, since the docs don't mention any possibility of this function doing anything other than returning a result or returning null, and my searching only finds discussions of how to fix the problem when you own the other side of the requests or generally actually need to access this header.

(Also kinda sorta related to #1399, which is about documentation of CORS issues.)

[matthiask]

First, is this just logged as an error or does it actually break anything? If it's the former we could add a banner (using console.log or something) on startup which tells people that this may happen and that people can just ignore it. If it breaks anything else it should be fixed. I assume that we do not get an exception or something there which we could catch and ignore though, so a solution may be a bit involved. Since all panels return JSON these days (not HTML) it should be relatively straightforward to insert the store ID as a field instead of sending it along as a header.

Or maybe we should just tell people how to configure their CORS headers so that this doesn't happen.

[xiongchiamiov]

It's just a logged error; as far as I can tell it doesn't break anything, just is confusing for developers and masks real errors.

It's not something that can be fixed by configuring CORS headers, unless you convince the entire internet to add djdt-store-id as a whitelisted header just in case someone happens to be using their site in a piece of software that's also using django-debug-toolbar. These are third-party requests that shouldn't be having any non-standard headers accessed, by design; the only reason this is happening is because the toolbar is (as befits a debug tool) aggressive about trying to inspect everything, even things that normally wouldn't be in the app's direct visibility.

[tim-schilling]

This appears to be an issue with Chromium. It's not an error, but an uncatchable warning. See this blog post for more info.

The solution is:

  if (xhr.getAllResponseHeaders().indexOf("djdt-store-id) >= 0) {
    store_id = xhr.getResponseHeader("djdt-store-id");
  }

I'll write up a PR

[xiongchiamiov]

Thank you! That explains why I couldn't find anything about it in general ES docs.