Consider whether or not CORS is the right long-term solution for allowed-origin security

[PropGit]

Manually-implemented HTTP over TCP gets around allowed-origin security in Chrome Apps- but will it do so always?

Consider this and whether or not to implement CORS in Parallax-ESP (which should be simple, but may require it be open to all, creating more attack vectors).

Current thoughts are not to expose this, but to stick with the TCP solution.

[pjewald]

We are using CORS in the Solo project to communicate with the BlocklyProp Client installed locally. This was required because the browser is initially communicating with solo.parallax.com. It then fails when the scripts obtained from solo.parallax.com attempt to communicate with the BlocklyProp Client HTTP interface located at localhost. The browser correctly identifies that solo.parallax.com and localhost are different domains.

I am concerned that the current HTTP implementation may not be properly handling this properly or at all.

[PropGit]

Can you describe exactly where this fails? I've never had problems with BlocklyProp Client and solo.parallax.com and just tested it again; no connection errors and downloads to Propeller are working fine for me.

[pjewald]

I would see the CORS errors in the browser debug console. I do not remember if anything actually broke - it's been a while.