absolute WFS-URLs als relativ behandelt

[Hans Tolle]

Absolute WFS-URLs funktionieren nicht

Beschreibung

Wird ein WFS mit einer URL auf einem fremden Server (bspw. "url": "https://geodienste.hamburg.de/HH_WFS_Verkehr_opendata", vgl. service-internet.json:415 im Beispiel) angelegt, so erreichen Requests von Daten diesen Server nie, sie werden (fälschlicherweise) an den aktuellen Host geleitet, wobei die URL verändert wird.

Requests zu Metadaten erreichen jedoch korrekt ihr Ziel.

Auswirkung

WFS können nicht angezeigt werden.

Schritte zur Reproduktion

1. Herunterladen & entpacken der aktuellen Stable-Version (aktuell: 2.5.4)
2. Bereitstellen des Portals auf einem Server (bspw. python3 -m http.server 8082 im entpackten Verzeichnis)
3. Master-Portal-Beispiel öffnen (hier: http://localhost:8082/Basic/); evtl. hier Überwachung der Requests starten
4. WFS-Layer (z.B. “Bike and Ride Parkplätze”) im Themenbaum anwählen

Erwartetes Verhalten

Der WFS-Layer wird angezeigt.

Tatsächliches Verhalten

Der WFS-Layer wird nicht angezeigt.

(Vermutete) Ursache

Korrekterweise müsste die entsprechende Anfrage an die URL https://geodienste.hamburg.de/HH_WFS_Verkehr_opendata?REQUEST=GetFeature&SERVICE=WFS&SRSNAME=EPSG%3A25832&TYPENAME=bikeandride_os&VERSION=1.1.0 gehen.

Tatsächlich wird aber der aktuelle Server angefragt:

http://localhost:8082/geodienste_hamburg_de/HH_WFS_Verkehr_opendata?REQUEST=GetFeature&SERVICE=WFS&SRSNAME=EPSG%3A25832&TYPENAME=bikeandride_os&VERSION=1.1.0

Dabei wurde das Schema (Protokoll) der eigentlichen URL entfernt und im Host-Teil die Punkte zu Unterstrichen (_) umgewandelt.
Die so modifizierte URL wurde an den aktuellen Server unter dem Pfad / gestellt (wohlgemerkt nicht relativ zum aktuellen Verzeichnis Basic).

Interessanterweise findet diese Ersetzung nur bei Daten-Requests statt; der erste Requests (DescribeFeatureType) wird korrekt gestellt. (siehe Screenshot im Anhang)

Workarounds

Start der URL mit //

Beginnt die URL in der Config mit // so wird die Anfrage mit dem aktuellen Protokoll (http bzw. https) an den Host gestellt, der auf // folgt, jedoch werden nach wie vor Punkte durch Unterstriche ersetzt.

Dieser Workaround ist daher praktisch nicht nutzbar.

Reverse-Proxy

Der Lokale Server des Masterportals kann konfiguriert werden, um Anfragen an fehlerhafte URLs (http://localhost:8082/geodienste_hamburg_de/...) auf die korrekten URLs umzuleiten (https://geodienste.hamburg.de/...).

Ich konnte diesen Workaround noch nicht testen, er müsste aber allen Anzeichen nach funktionieren.

Jedoch ist er sehr wartungsintensiv und daher nicht sinnvoll nutzbar.

Verwendete Browser

• Firefox 68.11.0esr (64-Bit)
• Chromium Version 83.0.4103.116

‌

[mbgvhh]

Hallo, dieses Verhalten ist tatsächlich so implementiert um die CrossOrigin-Policy der Browser zu umgehen. Die Implementierung der im MP benutzten Proxy-Pattern muss im Webserver erfolgen und sind somit nicht teil des Masterportals selbst. Siehe auch https://bitbucket.org/geowerkstatt-hamburg/masterportal/src/stable/doc/proxies.md

Dass das eine Pflege der URLs serverseitig voraussetzt ist nicht optimal. Alternative wäre, dort einen offenen Proxy zu konfigurieren, wovon aber aus Sicherheitsgründen abzuraten ist. Evtl. könnte man diesen bzgl. der angefragten Inhalte einschränken.

Um das Portal lokal unter localhost laufen zu lassen, ist in der lokalen Entwicklungsumgebung schon ein webserver inkl. entspr. proxy-regeln enthalten.

Am einfachsten wäre es für den produktiven Betrieb wahrscheinlich, eine CORS-Policy im Webserver der angefragten Dienste zu implementieren, so machen wir das in HH. Dazu muss man natürlich Zugriff auf die Diensteseite haben.

[mbgvhh]

Dies ist kein bug, sondern gewolltes Verhalten. Hinweise zum Umgang damit siehe letzter Kommentar.