CORS error when behind reverse proxy

[tim42]

After updating copyparty, I got those errors when trying to upload a file:

Feb 28 18:19:23 copyparty[574403]:  BTW: [H] accept: [*/*]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] accept-encoding: [gzip, deflate, br, zstd]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] accept-language: [en-US,en;q=0.5]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] cache-control: [no-cache]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] content-length: [142]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] content-type: [text/plain;charset=UTF-8]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] cookie: [js=y; cplng=eng]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] host: [somehost.tld]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] origin: [https://somehost.tld]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] pragma: [no-cache]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] referer: [https://somehost.tld/shared_data/]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] sec-fetch-dest: [empty]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] sec-fetch-mode: [cors]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] sec-fetch-site: [same-origin]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] sec-gpc: [1]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-forwarded-for: [192.168.x.y]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-forwarded-host: [somehost.tld]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-forwarded-proto: [https]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-forwarded-protocol: [https]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-forwarded-ssl: [on]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-forwarded-uri: [/shared_data/]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-original-url: [https://somehost.tld/shared_data/]
Feb 28 18:19:23 copyparty[574403]:  BTW: [H] x-url-scheme: [https]
Feb 28 18:19:23 copyparty[574403]: WARN: cors-reject POST because request-header Origin='https://somehost.tld' does not match request-protocol 'http://' and host 'somehost.tld' based on request-header Host='somehost.tld' (note: if this request is not malicious, check if your reverse-proxy is accidentally modifying request headers, in particular 'Origin', for example by running copyparty with --ihead='*' to show all request headers)
Feb 28 18:19:23 copyparty[574403]: WARN: http403: rejected by cors-check (see fileserver log), '/shared_data'

For context, copyparty is behind a reverse proxy which handle the HTTPS connection. Copyparty is connected via HTTP to the reverse proxy (same VM, with a private container network, so https would be a pure waste of resources with no added securty)
Is there a way to tell copyparty to just... ignore this check? (or to use x-forwarded-ssl instead?)

Because yes, there is a protocol mismatch, but no, it's not an error. (having a reverse-proxy to exit a VM is pretty common).
I could cheat and have nginx change origin to have http instead of https, and it works, but... this is not the correct behavior I feel.

And for reference, the other question is about the reverse of this situation. Nginx correctly reports that the connection is with https.

[9001]

the reverseproxy is sending x-forwarded-proto: https which copyparty will read and use if everything else is okay, so this should be working just fine -- which means there's a reason copyparty is refusing to do that;

what's your config? are you getting any other warnings/errors?

[tim42]

That's the only warning/error I get for the connection. (I pasted a redacted version of what is printed for each connection).
My config:

[global]
  # tried this, just in case, didn't change anything
  acam: *

  e2ds  # enable file indexing
  e2ts   # enable multimedia indexing
  no-hash: .*
  z
  no-robots

  dbd: wal
  dbpath: /files/data/.cpdb   # necessary, xyz is mounted as RO
  hist: /files/data/.cpdb   # necessary, xyz is mounted as RO
  u2abort: 3   # allow the same user to cancel their downloads on a different machine

  # UI options
  grid
  gsel

  magic

  df: 500   # only accept uploads if there's at least 500GB of free space
  # do not follow simlinks outside the volume
  xvol

  # Get the real-IP of the client
  xff-src: lan
  xff-hdr: x-real-ip
  rproxy: -1

  # enable IdP support by expecting username/groupname in
  # http-headers provided by the reverse-proxy; header "X-IdP-User"
  # will contain the username, "X-IdP-Group" the groupname
  idp-h-usr: remote-user
  idp-h-grp: remote-groups

[/images/${u}]
  /files/images/${u}
  accs:
    r: ${u}

# some more volumes below

[tim42]

A thing to note, if I force-set the Origin header to http://somehost.tld copyparty correctly works.

[9001]

xff-hdr: x-real-ip

this header is not being sent from your reverseproxy, so this is why it is not working. The default value is X-Forwarded-For so removing the line fixes it. Where did this come from?

[tim42]

I had x-real-ip setup in nginx, but I guess I made a mistake in the setup and it's not being sent. Removing xff-hdr: x-real-ip fixes the problem.
I'll have to see in my nginx config why the header is not properly set, but that's a different problem.

Thank you so much for your help!