[BUG] Websocket error Version 1.5.8

[MicKress]

Hi, i updated the whiteboard app to version 1.5.8 - and a websocket error occured connecting to a whiteboard server. This doesn't happen with whiteboard app version 1.5.7. The whiteboard server can be reached via https

Nextcloud Version 33.03 (same with NC 32.09)

[reyhe66243]

I just ran into this exact same issue. The root cause seems to be stricter Content Security Policy (CSP) enforcement. If you are running the websocket server on a separate subdomain (e.g., [https://whiteboard.yourdomain.com]), the browser now blocks the fetch requests to endpoints like /status due to cross-origin restrictions. This silently breaks the JWT validation and throws the generic websocket connection error.

The fix is to route the websocket server through a sub-directory on your main Nextcloud domain (e.g., [https://yourdomain.com/whiteboard/]) so the browser treats it as a same-origin request.

If you are using Nginx (or Nginx Proxy Manager), add a custom location block to your main Nextcloud domain configuration.

[ThibautPlg]

I can second this issue.
The fix suggested by @reyhe66243 only works if you're hosting the websocket server on the same host, which is not ideal for us. As such we're without whiteboard collaboration since the app was upgraded recently.

[reyhe66243]

Hi @ThibautPlg ,

Just to clarify, the websocket server doesn't actually need to be hosted on the same physical host or machine. It only needs to be accessed through the same domain name (via a sub-directory) to satisfy Nextcloud's strict Content Security Policy (CSP).

If your Nextcloud instance and your Websocket server are on two completely different servers, you can still use this fix. Your main reverse proxy (the one handling Nextcloud's HTTPS traffic) simply needs to intercept the /whiteboard/ path and proxy it over your network to the IP address of your dedicated websocket server.

For example, your Nginx config on your main proxy would look like this:

location /whiteboard/ {
# This IP can point to a completely different physical server, VM, or container
proxy_pass http://<EXTERNAL_WEBSOCKET_HOST_IP>:3002/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
As long as the browser sees the traffic going to https://your-main-domain.com/whiteboard/, Nextcloud's CSP will allow the connection, regardless of where the backend node actually lives.

[Rowr21]

If you are using Nginx (or Nginx Proxy Manager), add a custom location block to your main Nextcloud domain configuration.

Hey,

Thanks for the advice on this, but it seems this doesnt work for me on 1.59: I added this to my nginx proxy-conf for nextcloud:

location ^~ /whiteboard/ {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        set $upstream_app whiteboard;
        set $upstream_port 3002;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }

And when navigating to the url I get "Cannot GET /whiteboard/" and errors in the whiteboard admin settings, "Websocket error"

My similar locations, like drawio, work fine:

    location ^~ /draw/ {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app drawio;
        set $upstream_port 8080;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    }

The whiteboard container is part of the same swag network as all the others, and seems to be reachable just fine. If I add a trailing slash to the proxy_pass, I can reach the url, but websocket still fails.

Just wondering if this is an issue on my end, or whiteboard? Thanks!

EDIT:

For some reason constructing the proxy_pass as usual doesn't work here, I switched to:

proxy_pass http://whiteboard:3002/;

and it works fine.