Execute Playground code on a separate origin #285
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aomarks
force-pushed
the
playground-domain
branch
3 times, most recently
from
def6033 to
de26055
Compare
aomarks
changed the title
Fix kaniko cache invalidation issue
aomarks
force-pushed
the
playground-domain
branch
from
07eaf26 to
9528090
Compare
aomarks
changed the title
|
A live preview of this PR will be available at the URL(s) below. |
sorvell
approved these changes
Apr 8, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #26
Why
We want to execute Playground code on a separate origin, so that scripts are completely isolated from the main origin. In particular, scripts loaded through the "share" feature are not controlled by us, and often are written by another user to the person running it.
On a site that has access to e.g. sensitive user data or APIs on the main origin, this would be very important for security. That's why Playground warns in the console when it detects same-origin execution.
Our site is 100% static, so there's pretty limited risks -- an attacker could e.g. modify some page content, navigate the main window, etc. If we did something like integrate with GitHub gists for shorter Playground URLs, then an attacker might then be able to make authenticated GitHub requests through shared Playground code. So it seems like a good idea to close this hole before launch.
How
We have a new Cloud Run service called
lit-dev-playground. Its URL is https://lit-dev-playground-5ftespv5na-uc.a.run.app/, and PR revisions have the samepr<PR>-<SHA>prefix that the main service has. When we go live, the URL will be https://playground.lit.devWhen we do an Eleventy build, the
PLAYGROUND_SANDBOXenvironment variable is rendered into the HTML everywhere we instantiate a<playground-ide>or<playground-project>using thesandbox-base-urlattribute. This attribute tells Playground to interact with a Service Worker at that URL, instead of the default one on the same origin.The server has a new
MODEenvironment variable switch. When it's set toplayground, it only serves thejs/directory, instead of the full site. It uses the same Docker image, so this shouldn't affect build time much -- just a bit of extra time to deploy two services.