Deaktivierung der aktomatischen Weiterleitung von der IP oder Domain ohne zusätzliche Pfade dirkekt zur EGrouware

Sophia_2004 2020-01-28 12:16:54 UTC #1

Auf dem zukünfigen Server mit EGroupware-Docker 19.1 befinden sich weitere PHP-Skripte und andere wichtige Inhalte.

Diese wurden immer bis zur Version 17.* problemlos per

https://IP [eine DNS-Eintrag für eine Subdomain existiert nicht]

aufgerufen.

EGroupware an sich wurde erst nach der Eingabe der URL
https://publicIPv4/egroupware"
aufgerufen.

Falls jemand versuchte innerhalb des Gebäudes sich
http://local-server-ip/egroupware
anzusehen, dann erfolgte automatisch die Weiterleitung an
https://local-server-ip/egroupware

So sollte das Verhalten auch bleiben und seit der Update auf die neuste Version mit Docker funktioniert der Teil der Weiterleitung von http --> https für /egroupware weiterhin.

Leider wird jetzt sofort, egal ob bei http oder https oder per interner oder externer IP, nach Eingabe von

immer direkt auf

weitergeleitet.

Um die eigentliche Webserver-Indexseite mitsamt der anderen Unterseiten zu erreichen muss man

eingegeben.

Warum hat sich dieses Verhalten geändert bzw. wie kann es unter Umständen angepasst werden? Was stellt den Hintergrund dieser Anpassung dar, dass URLs mit “/xyz” außer der EGroupware einmalig zunächst direkt aufgerufen werden müssen?
Falls keine Änderung möglich sein sollte, diese Änderung ab Version 19.1 aber nicht gewünscht sein sollte, dann müsste ich das als technisch unveränderbar weitergeben.

An der bisherigen Apache2-Konfiguration

/etc/apache2/sites-enabled:
lrwxrwxrwx 1 root root 35 Feb 23 2019 000-default.conf -> …/sites-available/000-default.conf
lrwxrwxrwx 1 root root 35 Feb 23 2019 default-ssl.conf -> …/sites-available/default-ssl.conf
lrwxrwxrwx 1 root root 27 Feb 23 2019 egroupware.conf -> /etc/egroupware/apache.conf

wurde nach dem Update meinerseits keine Veränderung (000-default.conf, default-ssl.conf) vorgenommen.

RalfBecker 2020-01-28 12:39:44 UTC #2

Aus verschiedenen Gründen leitet EGroupware / nach /egroupware/ weiter:

WebDAV unter Windows funktioniert nicht falls / nicht auf OPTIONS requests antwortet (was Nginx selbst nicht macht)
EGroupware Benutzer wollen nicht immer den vollen Pfad mit angeben
ein Redirect von / im Container selbst ist schwieriger, da nicht immer klar ist mit welchem Host und Protocol der Webserver auf dem Host angesprochen wurde.

Deshalb leiten wir für alle Webserver inzwischen auf dem Host / automatisch auf die EGroupware weiter:

github.com

EGroupware/build.opensuse.org/blob/master/server:eGroupWare/egroupware-docker-19.1/egroupware-docker/apache.conf#L25




RequestHeader set X-Forwarded-Proto "https" env=HTTPS
ProxyPass /egroupware/ http://127.0.0.1:8080/egroupware/ timeout=4000 connectiontimeout=600 acquire=3000 retry=6
ProxyPassReverse /egroupware/ http://127.0.0.1:8080/egroupware/


ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync timeout=4000 connectiontimeout=600 acquire=3000 retry=6
ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8080/Microsoft-Server-ActiveSync


RedirectMatch ^/.well-known/(caldav|carddav)$ /egroupware/groupdav.php/
RedirectMatch ^(/principals/users/.*)$ /egroupware/groupdav.php$1
RedirectMatch ^/$ /egroupware/index.php
RedirectMatch ^/egroupware$ /egroupware/index.php

github.com

EGroupware/build.opensuse.org/blob/master/server:eGroupWare/egroupware-docker-19.1/egroupware-docker/nginx.conf#L89


	# CalDAV & CardDAV autoconfig
	location ~ ^/.well-known/(caldav|carddav)$ {
		return 301 $redirectscheme://$host/egroupware/groupdav.php/;
	}
	location ~ ^(/principals/users/.*)$ {
		return 301 $redirectscheme://$host/egroupware/groupdav.php$1;
	}
	# Nginx does NOT use index for OPTIONS requests breakng WebDAV
	# for Windows, which sends OPTIONS / and stalls on Nginx 405 response!
	# This also redirects all requests to root to EGroupware.
	location = / {
		return 301 $redirectscheme://$host/egroupware/index.php;
	}
	# redirect /egroupware to /egroupware/
	location = /egroupware {
		return 301 $redirectscheme://$host/egroupware/index.php;
	}
}

Das kann man natürlich anpassen, auf die Gefahr hin zu vergessen was man gemacht hat und mit dem nächsten Update ein Problem zu haben.

Ich würde grundsätzlich den EGroupware Server nicht mit irgendetwas anderem vermischen, oder halt die extra Skripte samt ihrer Index Seite auf ein ein Verzeichnis oder einen anderen VHost verlegen.

Ralf