Websocket and CSRF Issues

Technical assistance
1

Infos:

  • Used Zammad version: 6.3.1-1721886578.f7062be2.noble
  • Used Zammad installation type: package
  • Operating system: Ubuntu 24.04
  • Browser + version: Thorium (Chromium) 122.0.6261.132

Expected behavior:

  • Websockets connect and CSRF verification passes.

Actual behavior:

  • On loading a page, two error appear in the browser console.

WebSocket connection to ‘wss://example.domain.net/ws’ failed: application-b820e7570fbedd664bf2d3065c01e42b6a02bb13b21dce74504f0fe02289f54e.js:109

WebSocket connection to ‘wss://example.domain.net:6042/’ failed: application-b820e7570fbedd664bf2d3065c01e42b6a02bb13b21dce74504f0fe02289f54e.js:109

I checked the console and

I, [2024-07-26T04:15:14.443800#788-541180] INFO – : CSRF token verification failed
I, [2024-07-26T04:15:14.443932#788-541180] INFO – : CSRF token verification failed! (Exceptions::NotAuthorized)

appears every 10 minutes or so which I think might be related.

Steps to reproduce the behavior:

  • Install Zammad from apt
  • Disable included webservers
  • Install Caddy webserver
  • Use this Caddy configuration:
Caddyfile

example.domain.net {

log {
    output file /var/log/caddy/zammad.access.log
}

root * /opt/zammad/public

encode gzip zstd

@static {
    path_regexp static ^/(assets/|robots.txt|humans.txt|favicon.ico|apple-touch-icon.png)
}

handle @static {
    file_server {
        precompressed gzip
    }
}

handle_path /.well-known/* {
    root * /var/www/html
    file_server
}

@websocket {
path /ws
header Connection Upgrade
header Upgrade websocket
}
reverse_proxy @websocket http://127.0.0.1:6042 {
header_up Host {host}
header_up X-Real-IP {remote}
header_up X-Forwarded-For {remote}
header_up X-Forwarded-Proto https
header_up Connection {>Connection}
header_up Upgrade {>Upgrade}
header_up X-Forwarded-Ssl on
}

@cable {
    path /cable
    header Connection *Upgrade*
    header Upgrade websocket
}
reverse_proxy @cable http://127.0.0.1:3000 {
    header_up Host {host}
    header_up X-Real-IP {remote}
    header_up X-Forwarded-For {remote}
    header_up X-Forwarded-Proto https
    header_up Connection {>Connection}
    header_up Upgrade {>Upgrade}
    header_up X-Forwarded-Ssl on
}

handle {
    reverse_proxy http://127.0.0.1:3000 {
        header_up Host {host}
        header_up X-Real-IP {remote}
        header_up X-Forwarded-For {remote}
        header_up X-Forwarded-Proto https
        header_up X-Forwarded-Ssl on
    }
}

}

I have changed {scheme} to https to no avail.

Thanks for any help!

2

I think we have no example config for caddy webservers. Maybe you could try to get help via chatgpt:

ChatGPT

I tried to insert the example config and convert it. Maybe you could play around with that or switch to nginx or apache2:

3

Funny enough that’s exactly where I got this config haha. I had some issues, with the conversion but got it to a point where things were mostly working except these issues. To clarify, I’m not having the issues of CSRF Verification Fail on login like a lot of people do, logins seems to work, but this shows in the logs, as well as the browser console showing the failed websocket connections.

4

This caddy config seems to work perfectly:

 example.com {
        @websockets {
                header Connection *Upgrade*
                header Upgrade websocket
        }
        reverse_proxy /cable 127.0.0.1:3000
        reverse_proxy @websockets 127.0.0.1:6042
        reverse_proxy 127.0.0.1:3000
        encode zstd gzip
}
1 Like
5

Thank you @fredsmith . According to Caddy Websocket Configuration - #2 by marcofirsching , nothing specific to WS should be required in the Caddyfile, but here it does not work without the lines you provided.

6

To be more specific: without these lines, I get error messages about websockets in the console of the browser. I do not know what impact it has.

7

Zammads mobile interface and (upcoming) new desktop view will require websocket connections and thus not work in various scenarios.

Websockets will be mandatory. In the current desktop view it will cause higher system load (Zammad server) and much higher data flow delay and thus is also not really desired.

8

Just FYI, if you have a docker-compose setup, currently, websockets won’t work and there’s no clear indication how to get them to work.

Additionally, in the recent version of ruby, the CSRF issues pop up again, and the documentation currently only addresses these for apache2, nginx was not updated.

Feel free to check out my nginx setup for a solution to both.

9

That is straight up not correct.
Docker Compose installations have their websockets functioning, if everything is configured as it needs to be. Please don’t bring up such statements. As websockets are going to be mandatory (and already strongly encouraged), we wouldn’t provide such a stack setup if it wouldn’t work.

10

Sorry, didn’t mean to. As I said in the linked forum post, this might be rooted in confusion on my part.

Here’s why I thought so, and I invite you to direct me to a better solution:
I have an nginx proxy already and want to integrate zammad with a docker compose setup.
The zammad-docker-compose readme doesn’t mention anything regarding how to setup an external proxy, just to modify the setup, but given nginx is embedded, one might assume to just forward all traffic to the exposed port 8080. In my case, this did not work, specifically websockets did not.
Now looking at the general configuration docs - which I am still not sure are general since they also mention docker compose: They refer to zammad_ssl.conf as a starting point for your nginx config. However, this seemed to me to be the nginx config used internally (roughly) - not directly applicable to a reverse proxy one, since it expects ports 3000 and 6042 to be exposed, which they arent for the default docker-compose setup.

So yeah, it left me confused, leading me to find two possible initial implementation paths, both of which you can see in my linked forum post.
In the end, I ended up with a (seemingly) working solution that is indeed a mix between them that is not documented, hence leading me to confidently state here that this is not a clearly supported setup, since, well, I did indeed not get them to work using the documentation and the default docker-compose setup.

I can now see that you can get it to work without exposing additional ports, by doing exactly what I did in my solution but just routing everything through the embedded nginx anyway (even though I could skip it for both /ws and /cable routes), but that is also not properly documented IMO.
I would be happy to help extend the zammad-docker-compose repository with a sample nginx reverse proxy config (distinct from the zammad_ssl.conf that I think is meant to be used without docker-compose).

Anyway, that’s just my understanding, I might be wrong in my assumptions, but I can confidently say that for my current setup, at the very least, the docs could use some improvements, and I’m happy to help.