Integration-test app throws errors when loading font and SVG files

[alexgibson]

Description

I noticed our run-integration-tests app doesn't load web fonts or SVG files. Not a huge issue, but it is possible that a test might fail should something like an SVG fail to load somewhere.

Steps to reproduce

https://test.bedrock.nonprod.webservices.mozgcp.net/en-US/firefox/new/

Expected result

Both web fonts and SVG files should load as expected.

Actual result

Fonts get a CSP error:

Content-Security-Policy: The page’s settings blocked the loading of a resource at https://storage.googleapis.com/media/protocol/fonts/Metropolis-Bold.6a80125e795a.woff2 (“font-src”).

SVG files seem to get a 403 when trying to load from https://storage.googleapis.com/

Environment

N/A

[alexgibson]

Thinking about it it's probably fine to let the fonts get blocked, but it would be good to make sure images load at least?

[janbrasna]

I've elaborated a bit on this here: #9869 (comment)
(fonts CSP fixed, CORS issues for fetch/anon assets, path/host issues when not run in root)

Because even if you allow wildcard origins in dev (or mirror the one from request origin, if you feel like keeping a restricted list of origins to let mirror back in responses), you'd still get prod.bedrock.prod.webservices.mozgcp.net that thinks it's "mozilla.org" (not "allizom.org" or anything else) in integration tests, so it hotlinks all the assets from mozilla.org not *.mozgcp.net because they're output as ://hostname/path not just /path — so not only fonts but also some SVGs (depending on the context how they're loaded, sometimes they're anonymous/fetch) fail CORS too. You can probably relax origin allows for allizom.org, but that won't help the test instances loading assets from mozilla.org 🤷

BTW the weirdest results are for manual pushes to integration tests branch, that run from yet another env test.bedrock.nonprod.webservices.mozgcp.net which links assets from storage.googleapis.com/bedrock-nonprod-test-media (subdirectory) and most of the bedrock code doesn't expect there ever might be a prefix, so a bunch of things is loaded relatively from that, but pointing at root, as /path… trying to load assets from storage.googleapis.com/media/protocol/img/*… etc., so with CORS errors you also get a couple dozen 403s from Goog not liking where we're trying to load stuff from;D I don't know how much of that really matters, just an observation there's more assets broken under different hostnames.

[janbrasna]

FYI there's also CORS issues with staging FxA:

(never noticed before, but seems consistent now in fxde/chromium§ — can't tell if it's bc of the 401 response or generally unrelated)