EGW behind nginx proxy

oxelamp 2023-05-17 09:15:22 UTC #1

I’m trying to replace our aging 1.8 with latest egw. I am mainly using its calendar/resources.
I installed fresh debian 11 with latest updates and egroupware-docker (23.1.20230503).

we have nginx reverse proxy for forwarding subdomains to different servers.
egfoo.example.com to 192.168.70.38 and bar.example.com to 192.168.70.48

it works well with other servers (old egw, nextcloud, random apache2 server etc)
but with egroupware-docker i have problems with push.
push works when i connect from internal network and also when i connect from outside using simple port forward.

I first tried using tls on both our nginx and egw, then only on our nginx and now both plain http with no success.
Is this configuration supported at all or am i overlooking something simple?

some lines from nginx access log when making a calendar entry:
When connecting from internal ip - everything works:

172.18.0.6 - - [17/May/2023:07:59:35 +0000] "POST /egroupware/push HTTP/1.1" 200 23 "-" "swoolepush/src/Backend.php"

when connecting from internal network but to foo.example.com:8480 (forwarded to egw-docker:80).
Works. Note that 70.1 is gateway/dns to subnet in which egw-docker resides.

192.168.70.1 - - [17/May/2023:08:01:05 +0000] "POST /egroupware/push HTTP/1.1" 200 23 "-" "swoolepush/src/Backend.php"

Same thing with connecting externally to foo.example.com:8480.
Adding now nginx. first connecting to http://foo.example.com, both nginx and backend http.
push is not working.
from egw:

84.50.xx.x - - [17/May/2023:08:51:23 +0000] "GET /egroupware/push HTTP/1.0" 401 41 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36" 192.168.70.1 - - [17/May/2023:08:51:31 +0000] "POST /egroupware/push HTTP/1.0" 200 23 "-" "swoolepush/src/Backend.php"

from our nginx:

84.50.xx.x - - [17/May/2023:08:51:23 +0000] "GET /egroupware/push HTTP/1.1" 401 41 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36" 192.168.70.1 - - [17/May/2023:08:51:31 +0000] "POST /egroupware/push HTTP/1.1" 200 23 "-" "swoolepush/src/Backend.php"

84.50 is remote ip i connected from.
our nginx https, backend http - similar story, but this time without 401s…
Refreshing page is the only way i could see created calendar entries.

our nginx http conf:

server { listen 80; server_name foo.example.com; location / { proxy_pass http://192.168.70.38/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $remote_addr; } }

egw nginx.conf:
changed only this part:

listen 80 default_server; set_real_ip_from 192.168.70.22; real_ip_header X-Forwarded-For; real_ip_recursive on;

70.22 is our nginx.

It didn’t work well with default settings and it was the same with egroupware-docker apache install.

RalfBecker 2023-05-17 10:58:31 UTC #2

The problem is your incomplete proxy configuration, it does NOT support/proxy websocket!

Have a look at our Nginx configuration, or simply use that instead of an extra Nginx:

github.com

EGroupware/build.opensuse.org/blob/master/server%3AeGroupWare/egroupware-docker-23.1/egroupware-docker/nginx.conf#L44




	# include other EGroupware parts like Collabora
	include app.d/egroupware*.conf;


	# proxy into EGroupware container
	location /egroupware {
		proxy_pass http://127.0.0.1:8080;
		include proxy_params;
		# to allow longer running requests like eg. backup or restore
		proxy_read_timeout    60m;
		# required for push / websocket
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "Upgrade";
	}


	# PHP in docroot
	#location ~ \.php {
	#	fastcgi_pass unix:/run/php/php7.0-fpm.sock;
	#	include fastcgi_params;
	#}

Ralf

oxelamp 2023-05-17 13:06:00 UTC #3

Ok, thanks for the hint, it’s working now with both http and https. Using the latter, naturally.
I actually had lines needed websocket for https connection, but i didn’t use it…
Another thing not working is websocket with tls frontend and plain backend.

At this moment it’s working with Letsencrypt.
How hard would be to use our own wildcard cert?
I think i got it half working on my last try.