fix: Ensure x-forwarded-port header is used in Forwarded header

[alukach]

What I'm Changing

This PR ensures that a x-forwarded-port header is used when constructing the forwarded header.

Backstory

We have been experiencing an issue in a Kubernetes environment where Links were being written with href values with incorrect origins. To be specific, they would point to localhost:8001 rather than localhost, where localhost is the public-facing host and :8001 is the port of the internal upstream STAC API. The network layout was such that we had a Traefik proxy in front of the STAC Auth Proxy. That proxy sets the x-forwarded-port header on requests that were sent to the STAC Auth Proxy. However, the request did not contain a forwarded header, so we would create one. The problem was that our current logic would not make use of the x-forwarded-port when created the forwarded header. Despite us forwarding the x-forwarded-port, the upstream STAC API would defer to the forwarded header and thus ignore the provided x-forwarded-port. This meant that the upstream STAC API would generate links for http://localhost:8001. Digging through stac-fastapi code, we can see that the port first is read from the host header and then possibly overridden by the value in forwarded:

https://github.com/stac-utils/stac-fastapi/blob/3b24f86bc538b8c1d6b86008845d5541f4f481e8/stac_fastapi/api/stac_fastapi/api/middleware.py#L87-L106

The current problematic flow looks something like this:

sequenceDiagram
    autonumber

    participant Client as Client
    participant Traefik as Traefik Proxy
    participant Auth as STAC Auth Proxy
    participant STAC as STAC API

    Client->>Traefik: HTTP request
    Note left of Traefik: host: http://localhost

    Traefik->>Auth: Forward request
    Note left of Auth: host: http://localhost
    Note left of Auth: x-forwarded-for: 192.168.65.1
    Note left of Auth: x-forwarded-host: localhost
    Note left of Auth: x-forwarded-port: 80
    Note left of Auth: x-forwarded-proto: http
    Note left of Auth: x-forwarded-server: 26a4cc50fa1a

    Auth->>STAC: Forward request (proxied)
    Note left of STAC: host: http://stac:8001
    Note left of STAC: x-forwarded-for: 192.168.65.1
    Note left of STAC: x-forwarded-host: localhost
    Note left of STAC: x-forwarded-port: 80
    Note left of STAC: x-forwarded-proto: http
    Note left of STAC: x-forwarded-server: 26a4cc50fa1a
    Note left of STAC: via: 1.1 stac-auth-proxy
    Note left of STAC: forwarded: for=192.168.65.1 host=localhost proto=http path=/stac

    STAC-->>Auth: Response document
    Note left of Auth: links point to http://localhost:8001/...

    Auth-->>Client: Response (unchanged body)

Loading

Unfortunately, our link rewriting middleware would miss these links as it was looking for the internal upstream url stac:8001 and not localhost:8001. This is maybe besides the point, as the link rewriting middleware is really about cleaning up paths and in an ideal world we expect the upstream STAC API to properly make use of the forwarded header to properly construct links (which stac-fastapi-pgstac does decently well).

some more thoughts about x-forwarded-port

Reading the MDN docs on the forwarded header[^1], we see:

The alternative and de-facto standard versions of this header are the X-forwarded-For, X-forwarded-Host and X-forwarded-Proto headers.

The lack of mention of x-forwarded-port led me to believe that the X-forwarded-Host included the port. However, that doesn't not seem accurate when reviewing Traefik behavior.

How I did it

The fix was pretty simple: ensure that the host within the forwarded header contained the x-forwarded port.

How you can test it

Docker image of this build available here: https://github.com/developmentseed/stac-auth-proxy/releases/tag/v0.10.2-rc2

[pantierra]

Tested it with a local eoAPI cluster setup. Works well. Thanks!

[alukach]

Ultimately, I think that this is a bug in stac-fastapi, but we will work around that with this.