Per-example HTTP header setting / SharedArrayBuffer examples

[hamishwillee]

The SharedArray and Atomics examples don't work! because the security requirements for SharedArrayBuffer require that these headers are set:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

@schalkneethling Is it possible to update the infrastructure such that we can set set a few server headers on a per-example basis? (both on the live version and on the local server?)

Any example that uses (including the atomics example referenced by this issue) will otherwise fail. If the answer is "No" then perhaps we should strip these examples from the set here, and put in some kind of warning if someone tries to use them?

[schalkneethling]

@mdn/core-dev Please see @hamishwillee question above. Thank you.

[hamishwillee]

@mdn/core-dev - ping?

[caugner]

Thanks for the ping, TIL about those headers. I think we have a manually deployed AWS Lambda that sets response headers for the interactive examples and I will be looking into it next week.

As for the local server, this should be doable in yari.

[hamishwillee]

@caugner Any further thoughts on this one?

[NiedziolkaMichal]

How about making BOB use express instead of http-server and allow interactive examples meta.json files to list HTTP headers which should be set for an individual example? @caugner I would be up for it.

[caugner]

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

@hamishwillee Can you elaborate on which domain those headers need to be set (i.e. on developers.mozilla.org, or on interactive-examples.mdn.mozilla.net)?

How about making BOB use express instead of http-server and allow interactive examples meta.json files to list HTTP headers which should be set for an individual example?

Unfortunately, this would only be a local solution. On stage/production, the interactive examples are served as static files via Amazon Cloudfront and AWS S3, without using http-server.

[caugner]

@hamishwillee Let me know if this is still important to you. :)

[NiedziolkaMichal]

@caugner It's important because examples like SharedArrayBuffer.slice don't currently work.
Headers Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp should be set for those pages:

• https://interactive-examples.mdn.mozilla.net/pages/js/sharedarraybuffer-bytelength.html
• https://interactive-examples.mdn.mozilla.net/pages/js/sharedarraybuffer-constructor.html
• https://interactive-examples.mdn.mozilla.net/pages/js/sharedarraybuffer-slice.html

I think there might be consequences though. In BOB there is addPostMessageListener which listens to switchTheme in utils.ts in YARI. I think that setting Cross-Origin-Opener-Policy will block those requests and switching themes might not propagate to BOB properly.

[hamishwillee]

@caugner Yes: still interested, because this blocks the examples working.

I think these headers need to be set on interactive-examples.mdn.mozilla.net. My knowledge of CORS is weak, but my understanding is it is the origin that serves resources that decides how it will respond to cross-origin requests. In this case the iframe is embedded in developer.moz ... so it is the interactive examples that need to allow themselves to be served.

Note, my suggestion was a mechanism to dynamically allow headers to be set. For this particular case we know what the headers required are, but there might be other cases where other ones are needed.
Also, I'm worried about unintended consequences of settings these headers for "all examples".

[caugner]

@NiedziolkaMichal @hamishwillee To test this, I have added the two headers to stage.

See:

• https://developer.allizom.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/slice
• https://interactive-examples.stage.mdn.mozilla.net/pages/js/sharedarraybuffer-slice.html

The theme switching still works, but I'm still getting Error: SharedArrayBuffer is not defined.

Are we missing another header?

[NiedziolkaMichal]

@caugner I see that it works fine if the interactive example is displayed outside of an iframe.
The only reason that I can think of, is that the parent document also needs to be cross-origin isolated. If it doesn't work, I will do some testing on my own to find out.

[hamishwillee]

@caugner Back on Friday, I will also have a look then, unless @NiedziolkaMichal is able to debug this first!

[hamishwillee]

Sorry, I didn't get around to this, and might not today. Still on my list though.

[jeremylumanbailey]

Thank you guys for continuing on fixing this. I was about to post a duplicate issue about the example on the page still not working but found a chain leading to this page.

I can't help you guys work on the infra to fix this but I wish you best of luck getting this working again! 👍🙌

[hamishwillee]

The only reason that I can think of, is that the parent document also needs to be cross-origin isolated. If it doesn't work, I will do some testing on my own to find out.

@NiedziolkaMichal @caugner

I hesitate to comment because I'm not particularly expert, but this seems pretty likely from the security requirements:

For top-level documents, two headers need to be set to cross-origin isolate your site:

Of course that doesn't tell you for sure what your frame needs to do.

However you can run console.log(crossOriginIsolated); in the staging server on the page itself and on the standalone interactive example and get a different result - so clearly on MDN on the staging server it does not think it is crossOrigin isolated.

It's worth continuing to investigate, but if this proves "impossible" then we might be best launching the interactive examples rather than embedding them.

[hamishwillee]

@caugner Any thoughts on how we might progress this. We're outside my knowledge by quite a way.

[caugner]

I thought about this again, and we would probably need to set those two headers on both developer.mozilla.org and interactive-examples.mdn.mozilla.net.

However, the cross-origin isolation would effectively prevent us from accessing parent in the interactive-examples, which we currently use to count interactions with interactive-examples and which might be used to automatically adjust the height of interactive-examples.

So I asked internally now if there's anything we could do, e.g. mozilla/standards-positions#628.

[NiedziolkaMichal]

@caugner Maybe would it be possible to serve interactive examples from developer.mozilla.org? This way, the origin would be the same and we could access the parent.