Keyboard and mouse stopped working + content-security-policy error

[ygramoel (Johan Cockx)]

I’m running a self-hosted instance of Discourse at forum.embeetle.com. It has been running well for multiple years now.

This morning, I noticed that all keyboard and mouse interaction with the forum in the browser stopped working. I can load any page from the forum, but I cannot scroll, login, search, …

I tried both Firefox and Chromium: same issue.

Firefox developer tools show this error:

Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). forum.embeetle.com:362:10

I did not recently do any updates or install any new plugins.

Any suggestions on how I can debug and fix this?

AFAIK, I have a standard docker-based installation, except that I am running it behind an Nginx reverse proxy. Nginx config below (not sure it is relevant):

server {
    server_name forum.embeetle.com;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    ssl_certificate /etc/letsencrypt/live/embeetle/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/embeetle/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
    access_log /var/log/nginx/forum.embeetle.access.log;
    error_log /var/log/nginx/forum.embeetle.error.log;

    location / {
         proxy_pass http://unix:/srv/embeetle_forum/discourse/shared/standalone/nginx.http.sock:;
         proxy_set_header Host $http_host;
         proxy_http_version 1.1;
         proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
         proxy_set_header X-Forwarded-Proto $scheme;
         proxy_set_header X-Real-IP $remote_addr;
        error_page 502 =502 /error/offline.html;
        proxy_intercept_errors on;
     }
 
     location /error/ {
         alias /srv/embeetle_forum/error/;
     }
}

server {
    server_name forum.embeetle.com;
    listen 80;
    listen [::]:80;
    return 301 https://$host$request_uri;
}

[Moin]

It seems your site works fine in safe mode with themes disabeled.

[ygramoel (Johan Cockx)]

You are right.

I don’t remember ever setting a theme by default, but maybe I did and forgot about it.

I’d like to temporarily disable themes by default, so that our forum is usable while we figure out what is wrong with themes. How can I do that, if I can only access the admin pages with themes disabled? In safe mode, all themes are already disabled, and enabling and then re-disabling them seems to have no effect.

There are three themes available (see below). None of them is enabled by default.

Also, in safe mode there is no Content-Security-Policy error.

[Bas (Bas van Leeuwen)]

Strange, for me in Safari, it’s reporting that it refuses to execute line 315. Which is the inline script for the Discourse-spash preloader. So not theme related.

For an immediate fix, you could disable CSP using a site-setting:

Just speculating: If the issue than still persists, it might be your server environment sending something unexpected. Or another script interfering (are you running any custom plugins or other scripts?)

Note that that will leave you in a vulnerable state and should be remedied ASAP. But at least your forum is working again.

[ygramoel (Johan Cockx)]

@Bas

Strange, for me in Safari, it’s reporting that it refuses to execute line 315. Which is the inline script for the Discourse-spash preloader. So not theme related.

Yes, that is exactly what is happening for me.

I’ve implemented a different work-around for now, by adding a rewrite in the nginx config (at server level) as follows:

    rewrite ^(.*)$ $1?safe_mode=no_themes break;

So visitors will use safe mode by default now.

To allow further exploration of this issue, I have also duplicated the forum server without the rewrite at https://raw.forum.embeetle.com. If you visit that URL, you will still see the original issue.

I am not using any custom scripts. I am using some plugins, will experiment if disabling any of them has any effect.

[ygramoel (Johan Cockx)]

These are the plugins I am using:

chat was already disabled.

I tried disabling discourse-math, footnote and spoiler-alert; the problem persists.

[ygramoel (Johan Cockx)]

Found it: it was indeed an issue with my nginx configuration that now accidentally emitted a Content-Security-Policy header that is too strict for Discourse.

Removing the Content-Security-Policy fixed my issue.