code-server 4.0.0 behind nginx reports wrong port

[fritterhoff]

Using the following nginx configuration (fragment) in combination the SSL and code server reports port 80 in code-server instead of 443/https?

    location / {
      proxy_pass http://localhost:8080/;
      proxy_set_header Host $host;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection upgrade;
      proxy_set_header Accept-Encoding gzip;
    }

[benz0li]

Same problem with my setup. I'm running code-server via JupyterHub as part of a JupyterLab image with Traefik as a reverse proxy.

@code-asher @jsjoeio @bpmct You may check at https://vscode-r.jupyter.b-data.ch.
ℹ️ I have whitelisted your GitHub accounts for this deployment back in June.

[fritterhoff]

Propably completely independent from the proxy. Can reproduce it with Caddy and Apache ;).

[jsjoeio]

@fritterhoff do you mind posting repro steps for Caddy? I have experience with that so it'd be easier for me to investigate

[fritterhoff]

Well pretty simple and without any magic:

1. Configure Caddy:

mydomain.com {
  reverse_proxy 127.0.0.1:8080
}

2. Restart caddy
3. Start code-server
4. Open code-server in your browser
5. Recognize that the port in lower left corner is :80 and service-workers don't work

[fritterhoff]

@code-asher you mention in your last commit "does not work behind reverse proxies unless they send the right headers containing information about the proxied source" which headers would be required?

[code-asher]

Forwarded is the best one (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded) followed by X-Forwarded-Proto combined with either X-Forwarded-Host or Host.

[code-asher]

There might still be weirdness caused by the code explicitly adding an 80 or 443 to the authority but I think it will work if forwarding headers are set.

[fritterhoff]

Mhm okay than the current implementation may also have a bug as caddy sets some headers by default:

By default, Caddy passes thru incoming headers to the backend-including the Host header—without modifications, with two exceptions:

    It adds or augments the X-Forwarded-For header field.
    It sets the X-Forwarded-Proto header field.

So my upper example for caddy should work as expected and provide me an :443 as long as i access it via https.

[benz0li]

@code-asher Træfik sets X-Forwarded-Proto and X-Forwarded-Host headers (among others) at https://vscode-r.jupyter.b-data.ch.
ℹ️ See https://whoami.b-data.ch for all headers set by default by Træfik.

[code-asher]

Huh, interesting. There must be something else wrong with the code. I am curious as to the problem but I ended up just removing the logic entirely in favor of just setting it to location.host on the frontend so it should just work regardless of headers now. I might look into it later just to see what went wrong.

[code-asher]

I poked into it anyway but it seems like the forwarded headers should work:

> uri = getRemoteAuthority({ headers: { "X-Forwarded-Proto": "https", "X-Forwarded-Host": "vscode-r.jupyter.b-data.ch" }})
> `${uri.hostname}:${uri.port || (uri.protocol === 'https:' ? '443' : '80')}`
'vscode-r.jupyter.b-data.ch:443'

And yet it is actually setting the remote authority to "vscode-r.jupyter.b-data.ch:80".

I guess it is academic at this point but quite confusing. 😕

[code-asher]

Ah...the headers appear to be lowercased so they do not match. Not sure if they always come that way or if Express lowercases them. 🤦

So I guess forwarded should work since we have it lowercase but not the X- variants. But as mentioned next version will get rid of all this.

[voxsoftware]

still same problem

[tjpalanca]

As a temporary solution just in case this helps anyone, I've just made sure that X-Forwarded-Host returned the https://<code-server-url>:443 (hardcoded the 443 port) and everything works perfectly.

[rrgeorge]

I fixed this issue in Apache by adding a Forwarded header to my apache config as follows:
RequestHeader set Forwarded "for=%{REMOTE_ADDR}s;host=%{SERVER_NAME}s;proto=https"
Not sure exactly what the syntax is for nginx, but a similar approach should solve it.