Repository navigation
v3.1.0 doesn't work for me - Can't log in #1507
Description
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.
Metadata
Metadata
Assignees
Labels
No labels
Activity
fr0stf0x commented on Apr 12, 2020
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 commented on Apr 12, 2020
Hm will definitely fix, sorry about this. Looking into it. cc: @code-asher
filippo-orru commented on Apr 13, 2020
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 commented on Apr 13, 2020
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 commented on Apr 13, 2020
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 commented on Apr 13, 2020
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 commented on Apr 13, 2020
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 commented on Apr 13, 2020
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 commented on Apr 13, 2020
I have mine set to:
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 commented on Apr 13, 2020
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 commented on Apr 14, 2020
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 commented on Apr 14, 2020
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 commented on Apr 14, 2020
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. :)