[Bug]: express-rate-limit validation error when using with reverse proxy

[ankel]

Verified issue does not already exist?

• I have searched and found no existing issue

What happened?

Reproduce steps: run docker compose up with the following configurations

compose.yaml

services:
  traefik:
    image: traefik:latest
    restart: unless-stopped
    ports:
      - "80:80"
    volumes:
      - "./traefik.yaml:/etc/traefik/traefik.yaml"
      - "./traefik/data:/data"
      - "/var/run/docker.sock:/var/run/docker.sock"

  actual-server:
    image: actualbudget/actual-server:latest-alpine
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.actual-server.rule=PathPrefix(`/actual-budget`)"
      - "traefik.http.routers.actual-server.entrypoints=web"
      - "traefik.http.services.actual-server.loadbalancer.server.port=5006"
    volumes:
      - ./actual-data:/data

traefik.yaml

entryPoints:
  web:
    address: ":80"

providers:
  docker: {}

What error did you receive?

Once it's running, curl localhost:80/actual-budget will print the following error in the log:

ValidationError: The 'X-Forwarded-For' header is set but the Express 'trust proxy' setting is false (default). This could indicate a misconfiguration which would prevent express-rate-limit from accurately identifying users. See https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/ for more information.
    at _Validations.<anonymous> (file:///app/node_modules/express-rate-limit/dist/index.mjs:154:15)
    at _Validations.wrap (file:///app/node_modules/express-rate-limit/dist/index.mjs:287:18)
    at _Validations.xForwardedForHeader (file:///app/node_modules/express-rate-limit/dist/index.mjs:152:10)
    at Object.keyGenerator (file:///app/node_modules/express-rate-limit/dist/index.mjs:516:19)
    at file:///app/node_modules/express-rate-limit/dist/index.mjs:569:32
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async file:///app/node_modules/express-rate-limit/dist/index.mjs:550:5 {
  code: 'ERR_ERL_UNEXPECTED_X_FORWARDED_FOR',
  help: 'https://express-rate-limit.github.io/ERR_ERL_UNEXPECTED_X_FORWARDED_FOR/'
}

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Other

Operating System

Linux

[djm2k]

I've hotfixed this for my use here, by:

• repurposing the ACTUAL_TRUSTED_PROXIES env var as a number
• passing it to app.set('trust proxy', numberOfProxies) as recommended here
• modifying validateAuthHeader to just return true
  • not sure the implications of this, I assume express-rate-limit's proxy checker is OK? I use Authelia as another layer anyhow

Edit: See the below PR for a more thought-out approach, re-purposing the ACTUAL_TRUSTED_PROXIES env var.

[xadips]

Yup happens to me as well with nginx-proxy-manager setup since 24.8.0

[latetedemelon]

Confirmed this affects NPM starting with version 24.8.0

[maltokyo]

Also getting this error.
Setting ACTUAL_TRUSTED_PROXIES as per https://actualbudget.org/docs/config/#trustedproxies doesn't seem to allow me even to start up the server. What is the syntax of this in docker compose file, please?

[bdonvr]

Can confirm with Traefik as well

[developius]

Confirmed on Fly.io (not sure what they're using under the hood).

[cordlord]

Getting this with Cloudflare Tunnel as well.
Also tried the ACTUAL_TRUSTED_PROXIES variable with no luck.

Will test with ngnix tomorrow.

[KiARC]

It looks like existing PRs for this have been closed without merging, and this issue is fully preventing me from deploying an instance which to me indicates that it should be relatively high priority. Is there any progress on this since last week? If not, would you like me to take a look at the closed PRs and see if I can work to make any of them usable?

[cordlord]

Getting this with Cloudflare Tunnel as well. Also tried the ACTUAL_TRUSTED_PROXIES variable with no luck.

Will test with ngnix tomorrow.

I tested with ngnix and I'm still seeing the same error, however, excluding this from my compose file does not affect usability or the ability to deploy from what I can tell. Everything is working, including SimpleFIN linking and syncing, using the reverse proxy.