Blank white page after authentication when using Safari with Nginx reverse-proxy but works fine with Chrome #3850
Comments
jsjoeio
added
the
needs-investigation
|
Thanks for opening this bug report and posting the logs! We've had Safari issues in the past. I don't know if this is related, but what happens if you clear the cache and try again? Or try logging into your code-server instance from a private window? |
|
hi @jsjoeio , I have the same issue. clear cache is useless though I open a new web brwoser like Firefox or Microsoft Edge. |
|
Same issue here. I'm using MacOS 12 beat 3. Works fine on Edge but blank page on Safari. Clearing cache is useless. |
|
The other thing I'm wondering is if this is related to this #3829 |
jsjoeio
added
browser-safari
|
I tried reproducing locally with macOS + Safari but couldn't.
We will look into this for the next cycle. |
|
Thanks for looking into this. The key things to remember is that this occurs when using a reverse-proxy (in my case Nginx) with HTTPS certificates (I haven't tried it without HTTPS). Also, using the cert/cert-key method (without a reverse-proxy) works with Safari. I'm also using named paths (rather than IP's, which is a known problem with service workers). This problem also occurs with the official docker container too. I spun up another fresh instance and had caches cleared and it was a no go with Safari only. To be clear, the login screen shows up in Safari, but once I enter the password, I get a blank page. |
|
One more words, it works fine as I directly visit the code-server in LAN #3829 this issue mentioned ServiceWorker, I tried to replace path and it was fixed, but still output "time limit reached" error. BTW, console error:
Thanks |
Thanks for being specific about that! @code-asher any ideas?
Hmm 🤔 We thought that should fix it but maybe something else is happening. cc @code-asher here too.
Based on this and your screenshots, it seems like the json could be invalid? Have you tried copying and pasting your json file in a validator to double-check it? https://jsonlint.com/ |
|
Thanks @jsjoeio. For
|
Are the certificates valid (signed by a certificate authority and all that)? If not maybe Safari is being extra strict about them.
I think this is related to #2407. Basically I think we should probably remove the timeout entirely (but show a notification periodically so it doesn't look stuck).
This looks also to be related to the time out. Reading the file will fail if the connection is never established. |
|
@code-asher Yes the keys are valid and work well for all my other docker containers with reverse proxy (I have about a dozen). Even Code Server works in Safari to prompt the password. But fails after entering it with a white page. Also, as mentioned before, Code Server works if I use the built in cert/cert-key and not use a reverse proxy. All settings use FQDN. As a note, I don't believe the issue that user @fdddf is having is related. No amount of waiting cures the problem I'm having and my logs look different. Thanks! |
|
Ah do you get the green lock in the browser then?
I think Chrome and Safari might be refusing the web socket connections
because they do not think the certificate is valid. In my experience
this affects web sockets (and service workers I think?) but not HTML. Do
any of your other working containers make use of web sockets?
As for it only failing with a reverse proxy I'm not sure when/why
browsers decide a certificate is invalid; it might be that the
certificate needs to match the domain when there is one or something
like that.
One thing to try would be launching Chrome with
--ignore-certificate-errors and see if that works. If it does then it
definitely means the certificate is the issue. If not then it must be
the reverse proxy (or maybe code-server).
|
|
I don't think it's a key issue at all. They're valid Let's Encrypt Elliptic Curve keys. Also as I said, Chrome is working fine. Even Safari works up to the password prompt. But after I enter the correct password, I get a white page. I assume that is when web sockets are used? I'm not sure if the other apps use web sockets (Home Assistant, pgAdmin, Pi Hole, Grafana, Hoppscotch, custom Node/React site, etc). I also think I tried connecting through the reverse proxy without HTTPS and it failed. So I think your hunch about it being a web socket issue with Safari on Code-Server may be right. Are the pasted logs above any help? Also note my custom ports in the original issue statement. I don't know if ports can be funky with Safari and web sockets. |
|
Yup, after login is when the web sockets are connected and VS Code
doesn't show any UI until after the connection occurs (thus the white
page).
Ah my bad, I missed that you used Chrome and it worked so my flag
suggestion is pointless. If Safari also doesn't work with HTTP through a
reverse proxy that certainly seems to indicate the certificates are not
the issue especially if you're using Let's Encrypt.
If Chrome works it would seem to suggest it's not a reverse proxy issue
either. Quite confusing.
The logs indicate the web socket was closed locally by the browser (code
1006). The ways I've seen this happen in the past are if the browser
rejects the certificate or if the reverse proxy isn't correctly set up
to proxy web sockets but those don't appear to apply here.
The other interesting line is:
```
WebSocket network error: The operation couldn’t be completed. (OSStatus error -9836.)
```
I haven't seen this before but the name for -9836 is
`errSSLPeerProtocolVersion`
https://www.osstatus.com/search/results?platform=all&framework=Security&search=9836
One answer on Stack Overflow suggests it's fixed by additionally
allowing TLSv1.2 but again you said it's also broken with HTTP so I'm
not sure if this will even apply here or if there are additional
problems. Here's the link though just in case it's helpful:
https://stackoverflow.com/questions/62352790/websockets-not-working-on-ios-and-safari-ossstatus-error-9837
|
same issue, did you find solution? |
|
I'm getting this issue when trying to access with my iPhone |
|
@code-asher I'm sorry that I've been so busy these last couple months to check into this issue, but your thorough response was not in vain because you nailed the issue exactly! It seems Apple does not yet support TLS 1.3 on web sockets! So bizarre and strangely behind! For anyone running an Nginx reverse proxy, I have a ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';Thanks again @code-asher for your help! I'm going to close this issue now. |
|
I am elated we got to the bottom of it!
I will add a note about this to our docs.
|
* Mention that Safari needs TLS 1.2 #3850 * Delete duplicated guide sections
code-asher
removed
the
needs-investigation
OS/Web Information
code-server --version: v3.11.0Steps to Reproduce
Actual
Chrome works fine, though it also has errors in the console. I have coded projects with it just fine, but Safari fails after trying to sign in. I enter the pasword and press enter and I get a white page. No number of refreshes corrects the issues (and it no longer asks me for the password unless I purge cookies or launch a new private tab). I prefer Safari when on battery as I get an extra several hours of usage.
Logs
The Safari (results in white/blank page) and Chrome (works correctly despite errors) console logs are below. As a note, I've changed the domain to be nas.domain.com for privacy and this is after entering the correct password and pressing submit:
Safari
Chrome
Notes
This issue can be reproduced in VS Code: No
The text was updated successfully, but these errors were encountered: