v3.1.0 doesn't work for me - Can't log in

[filippo-orru]

Hi, I've just updated from an older 2.x version to v3.1.0 but I cannot login. It keeps redirecting me from / to /login?to=%2F.
I downgraded to v3.0.2 and that works fine.
Only lead I can give is that this error is logged in chrome:

The service worker navigation preload request was cancelled before 'preloadResponse' settled. If you intend to use 'preloadResponse', use waitUntil() or respondWith() to wait for the promise to settle.

[fr0stf0x]

Same here for me. Just use the older 3.0.2 version and it works. Yet ignore update to 3.1.0 notification until this is fixed

[kylecarbs]

Hm will definitely fix, sorry about this. Looking into it. cc: @code-asher

[filippo-orru]

I'm definitely willing to help reproduce and debug. I'm guessing it works on your machine, else you wouldn't have pushed it.

[code-asher]

Hmm, so far I haven't been able to replicate. It should only redirect when it doesn't find the correct key in the cookies so maybe something is wonky there.

Could you check the Chrome dev tools and see what the key cookie's domain and path values are? (Application tab > Cookies in the sidebar).

For example when I log in I get a single key cookie set to .8080.dev.localhost and /.

[code-asher]

Mostly just looking to see if you have more than one cookie or if the domain or path doesn't match the URL you're browsing.

[filippo-orru]

When I run on clean download with only --host 0.0.0.0 and access ip:port directly, it works perfectly fine but when I run with --port 8843, which is then relayed by nginx to be accessible on my url, it doesn't work. The first time, the cookie is set, the second time, I can't seem to find any.
So it probably has something to do with nginx proxy sitting between the two.

[code-asher]

Oh hmm one thing that changed in 3.1.0 was that we added the domain to the cookie. It'll use the host header. If it's blank or not set it won't set the domain (that will result in the same behavior as pre-3.1.0), otherwise it'll use the host header directly as the domain.

Does your nginx configuration do anything interesting with the host header, maybe?

[filippo-orru]

Can't check right now, I'll get back to you tomorrow. I think it only uses proxy-pass localhost:8443 but I might have some more lines setting headers.
What should the host header be exactly? Just example.com?

[code-asher]

I have mine set to:

proxy_set_header Host $host;

I just tested without setting a host header and now I can't log in. That seems like a bug so I'll look into it.

[code-asher]

Sorted it out; thanks for the bug report! The current workaround until the next version comes out with the fix is to set the host header in the proxy config.

[filippo-orru]

Thanks so much for the support and quick fix! I'll just skip that version and go straight to the next one, when it comes out .

[cstrat]

I have mine set to:

proxy_set_header Host $host;

I just tested without setting a host header and now I can't log in. That seems like a bug so I'll look into it.

I also had this same issue, I thought that I needed to pass a proxy-domain argument into code-server to fix the login issue. This seemed to do the trick though!

[code-asher]

Oh, yeah, I can see how that flag would be confusing! For anyone that's curious, the --proxy-domain flag is for configuring code-server's own built-in proxy and won't affect behavior with external proxies like nginx.

I've just tagged 3.1.1 so we'll have a release with this fix out soon so the host header will no longer be required for logging in. Although it's probably not a bad idea to forward the host information anyway. :)