Collaboration never connects when y-provider reaches the backend directly: SECURE_SSL_REDIRECT 301s the internal call

Start in src/frontend/servers/y-provider/src/api/collaborationBackend.ts and inspect the request headers used by fetchCurrentUser and fetchDocument, then compare them with the SECURE_PROXY_SSL_HEADER behavior in src/backend/impress/settings.py. Reproduce the internal request with and without X-Forwarded-Proto and confirm that collaboration connects without the redirect or TLS error.

Summary

On a self-hosted deployment where the y-provider reaches the backend over the internal docker network (COLLABORATION_BACKEND_BASE_URL=http://docs-backend:8000), no collaboration connection can ever be established. Every onConnect fails with Backend error: Unauthorized.

The cause is not authentication. It is SECURE_SSL_REDIRECT.

Mechanism

1. Production.SECURE_SSL_REDIRECT = True is hardcoded in src/backend/impress/settings.py and cannot be driven by an environment variable.
2. Django only knows TLS is terminated in front of it via SECURE_PROXY_SSL_HEADER = ("HTTP_X_FORWARDED_PROTO", "https").
3. The y-provider's internal call does not go through the reverse proxy, so nothing sets that header. Django answers 301 to https://docs-backend:8000.
4. The client follows the redirect and speaks TLS to a port serving plain HTTP.

src/frontend/servers/y-provider/src/api/collaborationBackend.ts builds requests with a fixed header set:

headers: {
  cookie: requestHeaders['cookie'],
  origin: requestHeaders['origin'],
  'X-Y-Provider-Key': Y_PROVIDER_API_KEY,
},

Nothing from the incoming request is relayed, so every call is affected — fetchCurrentUser and fetchDocument alike. This is not limited to unauthenticated probes.

Reproduction (from inside the y-provider container, v5.4.1)

$ wget -S --spider http://docs-backend:8000/api/v1.0/config/
  HTTP/1.1 301 Moved Permanently
  Location: https://docs-backend:8000/api/v1.0/config/
  ...
  error:0A00010B:SSL routines:tls_validate_record_header:wrong version number
  wget: error getting response: Connection reset by peer

$ wget -S --spider --header="X-Forwarded-Proto: https" http://docs-backend:8000/api/v1.0/config/
  HTTP/1.1 200 OK

Backend log showed 46 × 301 Moved Permanently on /api/v1.0/documents/<id>/ within the last 200 lines, all from the y-provider's container IP.

y-provider log before:

onConnect: backend error write EPROTO ... wrong version number
[onConnect] Backend error: Unauthorized

after setting the header:

Connection established on room: ba8c9fba-… canEdit: true

Why it can go unnoticed

Document creation through the conversion endpoint works fine — it is a different path. An instance can look healthy, list documents, and still be unable to open a single one for editing. Ours was in that state from day one and we only found it while verifying an unrelated deploy.

Possible fixes

The smallest one is to set the header on the internal call in collaborationBackend.ts:

'X-Forwarded-Proto': 'https',

We are running that on our instance and collaboration works. Happy to send it as a PR.

That said, you may prefer a different shape — relaying the incoming x-forwarded-proto instead of hardcoding it, exempting the API paths from the redirect, or simply documenting that COLLABORATION_BACKEND_BASE_URL must point through a proxy that sets the header. Tell us which you'd rather have and we'll write it that way.

Also happy to be told we have misconfigured something — but SECURE_SSL_REDIRECT not being env-driven leaves little room to avoid this when the internal call is plain HTTP.

Happens on v5.4.1 and the code is unchanged on main at the time of writing.