Enforcing dark mode not working in production about docusaurus

[OzakIOne]

I don't have any issues trying to reproduce your configuration locally on my macbook with docker, the website loads by default with darkmode theme enabled

[maddin79]

I tried it now with a local docker NGINX too and it worked. Could lead a setting in NGINX to this problem?

[slorber]

We don't know, what could be the problem, but it seems solved. If you (and us) can reproduce the problem deterministically, we'll reopen, otherwise we assume it was a human mistake

[maddin79]

I'm sorry but it is not solved. I still have the problem on my live system. I tried only with a local docker nginx and with this the problem was not happening.
I hope anyone has a hint for what could be the issue.

[Josh-Cena]

Did you try loading it in private browsing? Did you try any other hosting solution than Nginx? If this is specific to one setup it doesn't sound like a Docusaurus bug and should not be reported here.

[slorber]

If we cannot see the live system, its source code, and config, we cannot help more.

If your domain host other sites, it is possible that you encounter a storage key conflict, see https://docusaurus.io/blog/releases/3.4#site-storage---experimental for details

[maddin79]

I also think that it can not be Docusaurus, because locally it works. That is really weird.

Yes, I tried private browsing @Josh-Cena, with no luck.

@slorber I'll check that with the key conflict. And I will copy my production config into a docker container to play around with it. I'll come back to you with the result. Thanks for the help.

[slorber]

The easiest for us is that you share the URL of your live deployment.

[maddin79]

@slorber Sorry, late reply. Something else popped up.
Yes, of course. Here it is: https://md.turn-it.org/

[slorber]

Your site is served with a CSP header that prevents our inline script from running, you can see errors in the console logs.

Content-Security-Policy: script-src 'self'; object-src 'self'

md.turn-it.org/:6 Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self'". Either the 'unsafe-inline' keyword, a hash ('sha256-O8zYuOjyuzUZDv3fub7DKfAs5TEd1dG+fz+hCSCFmQA='), or a nonce ('nonce-...') is required to enable inline execution.

Here's what this script is doing FYI, it is required to get the theme work and avoid a flash of wrong theme before React hydrates

!(function () {
  function t(t) {
    document.documentElement.setAttribute("data-theme", t);
  }
  var e =
    (function () {
      try {
        return new URLSearchParams(window.location.search).get(
          "docusaurus-theme",
        );
      } catch (t) {}
    })() ||
    (function () {
      try {
        return window.localStorage.getItem("theme");
      } catch (t) {}
    })();
  t(null !== e ? e : "dark");
})(),
  (function () {
    try {
      const n = new URLSearchParams(window.location.search).entries();
      for (var [t, e] of n)
        if (t.startsWith("docusaurus-data-")) {
          var a = t.replace("docusaurus-data-", "data-");
          document.documentElement.setAttribute(a, e);
        }
    } catch (t) {}
  })();

[maddin79]

Hey @slorber, thank you so much. I totally overlooked this error. It works now :) .
Are there any plans to remove the inline scripts, if that is even possible?

[slorber]

Afaik it's not really possible to remove the inline scripts. At best we could make it so that it works for your specific use-case by hardcoding the dark data-theme attribute directly in the HTML doc, but for all other cases we'd still need the script to run.

This has been explained a bit here: #10231

[maddin79]

Ah, ok. For me it is fine and I also support your point of view in #10231. I'm not an expert in XSS or general website hacking, but I also do not really see an attack surface in this kind of website.

Thanks for the fast help and Docusaurus. Really appreciate it.