You have to change Nginx configuration: proxy_set_header X-Forwarded-Proto $scheme;
replace with proxy_set_header X-Forwarded-Proto https;
for “/” and “/ws” path.
if you like me did the whole instance configuration and couldn’t or don’t want to replace it with the new one, you can just remove nginx container and start the new one with own configuration. Before removing, inspect nginx container and match below docker run configuration.
This would have worked if i had installed zammad with docker. But zammad is just replying :
“Unable to find image ‘zammad/zammad-docker-compose:zammad-3.5.0-20’ locally”
Thanks @pqcomputers ! Worked for me after trying all other options found in documentation and other threads… there seems to be something missing somewhere, because we shouldn’t have to do such a modification.
Here is the list of what I’ve tried without success from the official documentation, and that I have unset to finally only keep your solution :
.env variable NGINX_SERVER_SCHEME (and others…) : didn’t work
same variable in docker-compose.override.yml : didn’t work
modification of my Apache frontend http server : didn’t work
We also struggled with this today and finally got it working again.
We have Zammad 4.0 behind a Hetzner Cloud Loadbalancer which does HTTPS / SSL and basically forwards Port 443 to Zammads Port 8080 (docker-compose). Note: our loadbalancer is basically only a proxy. We don’t load-balance at the moment… but it is just very easy to setup.
What we did:
Tell Zammad to use http (because we handle HTTPS outside in our loadbalancer proxy)
We could do this in the UI because we still had a user logged in fortunately.
restart Zammad
docker-compose down
docker-compose up -d
Basically this answer on github led me to the solution which shows the same thing using the rails console:
docker exec -it zammad-docker-compose_zammad-railsserver_1 bash
rails c
Setting.get('http_type')
=> "https"
Setting.set('http_type','http')
quit
exit
docker-compose down
docker-compose up -d
Why we had this problem at all?
I think what happend to us was this:
Initially this http_type setting is “http”. During our setup we changed it to https without noticing that this had this dramatic effect - because our admin user was still logged in.
But the problem appeared today a few days later, where we had to restart the server. Because then suddenly the “https” was used and other users were kinda locked out (except the admin session which was still logged in).
Bottom line is: if you are running behind an external Loadbalancer which handles SSL/ HTTPS for you, then you should leave the http_type=http.
