Ralf,
I agree, I think the “anonymous” user is fine and not the issue.
I think the issue is in my webserver configuration, to explain where I think the issue is, I need to explain my environment.
I only have 1 public IP, which means I can only have 1 'webserver". This server runs NGINX with PHP.
When eGroupware was installed with downloaded tar-files and later with git, this worked fine on my webserver.
Now that eGroupware comes in a docker-container, I ended up creating a 2nd server running docker and adding eGroupware as the first docker-application. I have to keep the existing webserver as-is to support various PHP websites.
I configured access to the docker-eGroupware using reverse-proxy settings and also run the egroupware-nginx container on the docker-host. But I also set the hosts-part in the docker-compose file to point to the IP-address of the main webserver. Setting this to the docker-host-IP causes failures as that one does not listen on HTTP or HTTPS ports.
The config I have on the main webserver is:
server {
server_name egw.example.org;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/egw.example.org/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/egw.example.org/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
#Redirect non-https traffic to https
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
access_log /var/log/nginx/egw.example.org.access_log;
error_log /var/log/nginx/egw.example.org.error_log;
client_max_body_size 65M;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://docker.example.org:8080;
proxy_read_timeout 90;
}
}
server {
if ($host = egw.example.org) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name egw.example.org;
return 404; # managed by Certbot
}
(actual domain name changed to “example.org”)
All this works for eGroupware and Rocketchat as they simple provide the client with the HTTPS URL and expect unencrypted data from the webserver.
The problem that, I think, Collabora is having is that it needs to contact eGroupware over HTTPS, but gets the information via HTTP.
In simple terms, I think the best solution is to configure HTTPS (along with the letsencrypt SSL-keys) and reconfigure the main webserver to blindly pass on the HTTPS requests directly to the docker host.
I know this is not the NGINX support group, but if you have any ideas on how to configure NGINX to blindly proxy HTTPS without needing the certificate files and get the egroupware-nginx container to handle the letsencrypt certificates, including renewal, than I think it should work correctly.
–
Joost
