Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection between p5.serialport and p5.serialserver use WS rather than WSS #48

Open
vanevery opened this issue Oct 9, 2018 · 6 comments

Comments

@vanevery
Copy link
Member

vanevery commented Oct 9, 2018

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

@vanevery
Copy link
Member Author

vanevery commented Oct 9, 2018

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

@vanevery
Copy link
Member Author

vanevery commented Oct 9, 2018

back to the future: http://www.aaronsw.com/weblog/ajaxhistory

@vanevery
Copy link
Member Author

vanevery commented Oct 9, 2018

Let's Encrypt may offer something here: https://letsencrypt.org/docs/certificates-for-localhost/

@vanevery
Copy link
Member Author

Everything I have considered, Let's Encrypt says "don't do".. Hmmn Perhaps AJAX is the only way to go??

@vanevery
Copy link
Member Author

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.

@gabrieldespindula
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants