Reverse Proxy und HTTPS

GoProject spricht einfaches HTTP auf APP_PORT. HTTPS endet an Ihrem eigenen Reverse Proxy (nginx, Caddy, Apache, ein Load Balancer) davor.

Was der Proxy tun muss

• WebSocket-Upgrades auf /ws durchlassen: die Header Upgrade und Connection (nginx: proxy_http_version 1.1 und beide Header; Caddy macht es von selbst). Ohne sie aktualisieren sich Boards, die Glocke im Posteingang, der Chat und gemeinsame Dokumente nicht live.
• Anfragen von mindestens 500 MB annehmen: Mehrere Anhänge gehen in einer Anfrage hoch, und die Anwendung nimmt bis zu 500 MB pro Anfrage an.
• X-Forwarded-Proto und X-Forwarded-For senden: Daraus erfährt die Anwendung die öffentliche Adresse und die IP-Adresse der Person.
• Strict-Transport-Security und Permissions-Policy selbst setzen: Die Anwendung sieht HTTPS nie und sendet sie daher nicht.
• Das Cookie XSRF-TOKEN und den Header X-XSRF-TOKEN unverändert lassen: Ohne sie wird jede Änderung mit 403 abgelehnt.

Ein Proxy mit öffentlicher Adresse

Die Anwendung glaubt den weitergeleiteten Headern nur von einem Proxy mit privater Adresse (10/8, 172.16/12, 192.168/16, Loopback). Hat Ihr Proxy eine öffentliche Adresse, nennen Sie genau diese Adresse in .env, zum Beispiel SERVER_TOMCAT_REMOTEIP_INTERNAL_PROXIES=203\.0\.113\.7; sonst verzeichnet das Audit-Protokoll den Proxy statt der Person. Nennen Sie nie einen größeren Bereich als den Proxy selbst.

Ein Test ohne Proxy

Für einen Test über einfaches HTTP ohne Proxy setzen Sie SESSION_COOKIE_SECURE=false in .env, sonst verwirft der Browser das Anmelde-Cookie und niemand kann sich anmelden. Setzen Sie es vor dem echten Einsatz wieder auf true.

Nach jeder Änderung an .env übernehmen Sie sie:

docker compose up -d