Repository navigation
Should serve user programs with a different origin #1193
Description
Shared Program: https://code.world/haskell#Pjuh_bMGIsr9fbGSkqV8bXQ
Description
This use of JavaScriptFFI allows the opportunity for someone to share a link that steals cookies from a user. The good news is that CodeWorld goes out of its way not to store any really sensitive info -- just an opaque identifier. But it's still not great that it's available via Base64-encoded token in a link. Ideally, student JavaScript would be served from a different origin, with no cookies.
Activity
cdsmith commentedon Oct 2, 2019
One issue here is that there is actually quite a lot of cross-frame communication going on, particularly when it comes to: (a) console output, and (b) debugging. Thankfully, the debugger already follows a pretty well-defined protocol, so hopefully shouldn't be too hard to convert to
window.postMessage.cdsmith commentedon Oct 2, 2019
It would be best, as well, if code from different projects were isolated and couldn't access each other's local storage and such. This is a lower priority for me, since they aren't expected to USE any local storage. More important to isolate student code from the surrounding web site.
cdsmith commentedon Oct 2, 2019
Here's a plan that I think will be valuable:
Rewire console and debugger access to use
window.postMessageInclude a
sandboxattribute on theiframefor loading student code within the development environment. This only partially mitigates the issue, but it's an important step.Add configuration options for requiring that student code is served from a different host name or port. This makes setup more complex, so it needs some thought on how to keep things easy for self-hosting, and should probably be made optional.
[-]Should serve user programs with a different origin from [/-][+]Should serve user programs with a different origin[/+]Convert most communication with student code to use window.postMessage.
More work on cross-domain accesses. This eliminates access from the