Droppy is not working on safari

[txchen]

The web UI cannot render correctly. Tested on iOS and OSX.

[silverwind]

Got a screenshot? Looks fine here on OS X:

[txchen]

It is all black

[silverwind]

Just guessing: Are you correctly proxying WebSockets through your nginx?

    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

https://github.com/silverwind/droppy/wiki/Nginx-reverse-proxy
http://nginx.org/en/docs/http/websocket.html

[txchen]

I opened dev tools and found this:

My setup:

I use nginx and forward to upstream droppy instance, in nginx, I use basic auth and I disabled auth in droppy.
Chrome and Firefox works well, safari cannot connect to ws

[txchen]

Oh Just saw your reply, I will have a try now.

[txchen]

My nginx setting (partial):

upstream droppy {
  server  127.0.0.1:9999;
}

location / {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/droppypasswd;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Real-Port $remote_port;
    proxy_set_header Host $http_host;
    proxy_pass http://droppy;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    add_header Strict-Transport-Security "max-age=31536000";
  }

[silverwind]

Hmm, that's pretty strange. Does the demo work? What Safari version?

[silverwind]

Also, try https://www.websocket.org/echo.html using secure WebSocket.

[silverwind]

Oh, and for an explanation on the 401 response on the WebSocket request: This response is given when no cookie is sent.

Maybe you're blocking cookies, or something else is making the cookie go missing. I think I'll fix that by removing cookie usage when in public mode, they're not really necessary unless authentication is enabled.

[txchen]

Thanks a lot for your reply! @silverwind

My browser supports websocket, and seems demo does not work well.

The menu is not rendered, and when I click the folder, it becomes black.

[txchen]

Safari Version 8.0.8 (10600.8.9)

[txchen]

And I don't think my settings are blocking cookies, as far as I know.

On the other hand, chrome and firefox have no issues.

[silverwind]

That rendering looks like some oddity of Safari 8. I'm on Safari 9 already, so I can't really fix that without a browser to test on I'm afraid. As for cookies, make sure it's at least set to this:

You could also try to set 'Always allow', but it shouldn't change anything in theory.

[txchen]

Tried 'always allow', still same issue.

[silverwind]

Luckily, I have a test page for this exact issue. Could you post the content of this site?

[txchen]

Sure, my safari:

HTTP headers received

{ host: 'wstest.silverwind.io',
  connection: 'upgrade',
  accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8',
  'accept-language': 'en-us',
  'accept-encoding': 'gzip, deflate',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Version/8.0.8 Safari/600.8.9' }
WebSocket headers received

{ host: 'wstest.silverwind.io',
  upgrade: 'websocket',
  connection: 'upgrade',
  origin: 'http://wstest.silverwind.io',
  cookie: 'some=value',
  pragma: 'no-cache',
  'cache-control': 'no-cache',
  'sec-websocket-key': '733l+YcTyY5Rfm6DwSDvwg==',
  'sec-websocket-version': '13',
  'sec-websocket-extensions': 'x-webkit-deflate-frame',
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/600.8.9 (KHTML, like Gecko) Version/8.0.8 Safari/600.8.9' }

[txchen]

From the nginx log. I see those 401 for ws requests from safari.

So I guess it is blocked by nginx's basicauth check, because the browser is not sending the authorization header.

Not sure if this is a browser bug or client code can workaround this.

[txchen]

Well, now I think this is a safari issue because it is not passing credential in wss request.

Is wss a must for droppy, can this be turned off?

[silverwind]

Ah, so the 401 is from nginx instead of droppy, that explains it. Other browser are probably sending basic auth data on the Websocket Update request, while Safari likely doesn't. I'll read up more/test this, but it sounds like a browser bug to me.

Is wss a must from droppy, can this be turned off?

When the server is on https, it's forced to be wss.

[txchen]

Actually I mean: does droppy have a non-websocket mode? I that mode, it does polling to get information from server?

[silverwind]

Ah, no. Unfortunately WebSocket is a must right now, but I'll think about adding a polling fallback.

[txchen]

Thanks a lot for your support! Sorry for the false alarm. I am closing this and will try to use droppy's account system instead.

Thanks again!

[silverwind]

No problem! I just verified the issue is present in Safari 9 too, so I guess it's bug report time :)

[raybellis]

https://bugs.webkit.org/show_bug.cgi?id=80362

[silverwind]

@raybellis I do not see any issues regarding websocket authentication on Safari 12.0, what are you exactly experiencing? The only websocket-related bug in Safari that I'm aware of is that it won't work with self-signed SSL certificates.

[raybellis]

I'm not using droppy, but found this github issue when searching for related help so dropped the link above for your reference.

In short, if you have a websocket and http on the same domain and port, Safari doesn't pass the credentials used for the HTTP request when subsequently talking to the websocket, so the proxy always returns 401.

[silverwind]

Interesting, thanks. Maybe I'll switch to in-line authentication on the Websocket to avoid it.