Reverse proxy and HTTPS

GoProject speaks plain HTTP on APP_PORT. HTTPS ends at your own reverse proxy (nginx, Caddy, Apache, a load balancer) in front of it.

What the proxy must do

• Pass WebSocket upgrades on /ws: the Upgrade and Connection headers (nginx: proxy_http_version 1.1 plus both headers; Caddy does it on its own). Without them boards, the inbox bell, chat and shared documents do not update live.
• Accept request bodies of at least 500 MB: several attachments go up in one request, and the application accepts up to 500 MB per request.
• Send X-Forwarded-Proto and X-Forwarded-For: the application learns the public address and the person's IP address from them.
• Add Strict-Transport-Security and Permissions-Policy itself: the application never sees HTTPS, so it does not send them.
• Leave the XSRF-TOKEN cookie and the X-XSRF-TOKEN header alone: without them every change is refused with 403.

A proxy on a public address

The application believes the forwarded headers only from a proxy on a private address (10/8, 172.16/12, 192.168/16, loopback). If your proxy is on a public address, name exactly that address in .env, for example SERVER_TOMCAT_REMOTEIP_INTERNAL_PROXIES=203\.0\.113\.7; otherwise the audit trail records the proxy instead of the person. Never name a wider range than the proxy itself.

A trial without a proxy

For a trial over plain HTTP without a proxy, set SESSION_COOKIE_SECURE=false in .env, otherwise the browser drops the sign-in cookie and nobody can sign in. Set it back to true before real use.

After any change to .env, apply it:

docker compose up -d