Hier wird im folgenden die proxyconf-Datei in ihrem Aufbau und ihrer Funktion beschrieben.

Warum brauche ich für die lokale Entwicklungsumgebung einen Proxy? #

Ein Proxy wird benötigt um Daten von anderen Resourcen, die von einer anderne Domain geholt werden, laden zu dürfen. Wenn im Browser versucht wird direkt auf diese Daten zuzugreifen werden diese aufgrund der Same-Origin-Policy geblockt.

Wie funktioniert ein Proxy? #

Der Proxy nimmt die Requests vom localhost an andere Domains an und stellt sie selber an die eigentliche Domain und leitet diese wieder zurück an den Browser. Somit kann das Problem umgangen werden. In der proxyconf_example.json bzw. proxyconf.json steht an welche Domain der unter localhost laufende Server den Request stellen soll.

Wie muss der Proxy für die Kartenviewer API konfiguriert werden? #

Im Beispiel ist der Proxyeintrag für die Kartenviewer API zu sehen, um in der lokalen Entwicklungsumgebung die Dienste über geodienste.beispiel.de zu nutzen.

Beispiel

{
  "/geodienste_beispiel_de": {
    "target": "http://geodienste.beispiel.de",
    "pathRewrite": {
      "^/geodienste_beispiel_de": ""
    },
    "agent": ""
  }
}

In der ersten Zeile des Objektes ist die vom Portal umgeschriebene Domain für die geodienste.beispiel.de Domain eingetragen. Darüber wird entschieden was der Proxy mit dem eingegangenen Request anstellen soll. Im Beispielobjekt gibt es verschiedene Parameter die genutzt werden können:

1. target: hier wird die URL eingetragen an welche Domain der Request gestellt werden soll.
2. pathRewrite: enthält hier im Beispiel eine Ersetzungsregel um die vorher umgeschriebene Domain aus dem Request zu entfernen.
3. agent: Wird verwendet, um aus einem Intranet über einen Corporate Proxy ein target im Internet zu erreichen. Der Value des agent wird beim starten des Servers automatisch aus dem Proxy der Systemumgebung (process.env) gefüllt.
4. Weitere Parameter sind unter https://webpack.js.org/ zu finden.

Es kann auch den Fall geben, dass ein ReverseProxy eines unserer Server genutzt wird. Dann findet dort eine erneute Anfrage an die eigentliche Domain statt und vorher wird der Parameter pathRewrite nicht verwendet. Vorteil hierfür ist, dass die Weiterleitungsregeln nur einmal auf dem Server eingetragen werden und nicht noch extra bei jedem lokal vorgehalten werden müssen.