This appears in Safari v10's log when attempting to use the demo site. It also appears when attempting to use my own instance, only with a different host.
[Error] Refused to execute a script because its hash, its nonce, or 'unsafe-inline' does not appear in the script-src directive of the Content Security Policy. (avatar.playat.ch, line 0)
[Error] Refused to connect to wss://avatar.playat.ch:1000/socket.io/?EIO=3&transport=websocket&sid=poPLFDv503UUVYB_AAKP because it appears in neither the connect-src directive nor the default-src directive of the Content Security Policy.
[Error] SecurityError (DOM Exception 18): The operation is insecure.
(anonymous function) (socket.io.js:1971)
doOpen (socket.io.js:1971)
open (socket.io.js:827)
probe (socket.io.js:400)
onOpen (socket.io.js:422)
onHandshake (socket.io.js:482)
onPacket (socket.io.js:444)
(anonymous function) (socket.io.js:276)
emit (socket.io.js:2556)
onPacket (socket.io.js:892)
callback (socket.io.js:1766)
(anonymous function) (socket.io.js:3558)
forEach
decodePayloadAsBinary (socket.io.js:3557)
decodePayload (socket.io.js:3325)
onData (socket.io.js:1770)
(anonymous function) (socket.io.js:1330)
emit (socket.io.js:2556)
onData (socket.io.js:1491)
onLoad (socket.io.js:1572)
onreadystatechange (socket.io.js:1444)
I assume this issue only affects the v10 betas of Safari.
Oh, this may actually be Apple's bug. I'll report it to them as well.
Essentially what's going on here is that Apple changed the way CSP is handled in recent versions of WebKit (Safari on Mac OS and iOS). To date, that version has only been released in beta form in Mac OS Sierra, iOS 10, and the Safari Developer Preview, but may be released with this broken in public form soon.
The issue ultimately is that rather than treating a wildcard as a wildcard in the Content Security Policy, it seems to only be allowing it over specific protocols, of which web sockets is not one, and outright blocking the connection.
The fix is simple. You just have to specifically say that the web sockets protocol is okay by changing the CSP line in src/server.js as follows:
res.setHeader("Content-Security-Policy", "default-src * wss:; style-src * 'unsafe-inline'; script-src 'self'; child-src 'none'; object-src 'none'; form-action 'none'; referrer no-referrer;");
I believe this is a bug in WebKit, and have reported it to Apple, but they have not yet fixed it, so the above fix may need to be implemented into The Lounge as a workaround in order to ensure it continues to work in Safari on iOS and Mac OS.
This could solve #578 perhaps.
It's still a bug on Apple's part, but the workaround should work, if you know how to apply it.
Most helpful comment
Essentially what's going on here is that Apple changed the way CSP is handled in recent versions of WebKit (Safari on Mac OS and iOS). To date, that version has only been released in beta form in Mac OS Sierra, iOS 10, and the Safari Developer Preview, but may be released with this broken in public form soon.
The issue ultimately is that rather than treating a wildcard as a wildcard in the Content Security Policy, it seems to only be allowing it over specific protocols, of which web sockets is not one, and outright blocking the connection.
The fix is simple. You just have to specifically say that the web sockets protocol is okay by changing the CSP line in src/server.js as follows:
res.setHeader("Content-Security-Policy", "default-src * wss:; style-src * 'unsafe-inline'; script-src 'self'; child-src 'none'; object-src 'none'; form-action 'none'; referrer no-referrer;");
I believe this is a bug in WebKit, and have reported it to Apple, but they have not yet fixed it, so the above fix may need to be implemented into The Lounge as a workaround in order to ensure it continues to work in Safari on iOS and Mac OS.