Connection between p5.serialport and p5.serialserver use WS rather than WSS
vanevery opened this issue · 6 comments
This is an issue as some browsers aren't allowing non-secure socket connections from secure origins. Chrome 69 allows it to localhost which helps but Safari and Firefox are blocking.
Need to figure out a way to allow WSS connections to work. This is also an issue with https://github.com/vanevery/p5.serialcontrol
from @aparrish
another random thought on this—according to the standard, web browsers are supposed to trust 127.0.0.1 (https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy) and based on the testing I've done, regular http requests to 127.0.0.1 work (across browsers) regardless of the origin domain. but for some reason Firefox and Safari didn't extend that same courtesy to websockets requests. so another potential fix would be to make a version of the serial server that works over plain http (possibly using long polling, like it's 2009 or something) instead of websockets? (recognizing that this idea doesn't help in the short term, but wanted to put it on the record in case people are consulting this thread in the future) -a
back to the future: http://www.aaronsw.com/weblog/ajaxhistory
Let's Encrypt may offer something here: https://letsencrypt.org/docs/certificates-for-localhost/
Everything I have considered, Let's Encrypt says "don't do".. Hmmn Perhaps AJAX is the only way to go??
As this issue is still open and rearing it's ugly head, I figured a recap here would be worthwhile:
The issue of only being able to use a p5 Sketch from the p5 Editor in Chrome when using p5.serialcontrol is unfortunately quite complex and any thoughts on this would be appreciated. Since the p5 Editor is now HTTPS only an ugly security related restriction pops up when using p5.serialcontrol. Specifically, a sketch run from the editor is in the "secure context" and browsers are therefore blocking non-secure resources such as the connection from the browser to the p5.serialcontrol (via an insecure websocket). Unfortunately, we haven't come up with a good way to make that websocket be secure without breaking all kinds of rules (such as distributing a certificate for localhost.itp.io that points to 127.0.0.1 or going back to 2009 as per @aparrish suggests above). Fortunately, Chrome, for now, follows the advice of the W3C and treats connections to localhost as secure (https://www.w3.org/TR/secure-contexts/#localhost ) as not doing so breaks all kinds of good things (such as p5.serialcontrol). Other browsers have not always followed suit especially when it concerns websockets as opposed to straight HTTP.
What about a Chrome extension? When using the online editor, instead of sending requests to localhost it could try to pass a message to an extension and the extension manages the COM interaction. It could show a friendly message at p5 editor if the extension isn't installed, requesting it.