CORS eats custom board backgrounds

[Archenoth]

So! When you set a custom board image, it loads nicely on most pages!

(Image source, plus a direct url link here if you wanted to test it)

However, on Puzzles, User Analysis, the normal Analyze page, Practice, Relay, and Studies, the board instead looks like this

And on these pages, this message shows up in the console:

I've narrowed it down to the server replying with "Cross-Origin-Opener-Policy: same-origin" when looking at a lot of pages (the broken ones)

...but not all! (the working ones)

These headers are added in this method!

lishogi/app/controllers/LilaController.scala

Lines 69 to 74 in 2bd070c

	protected def EnableSharedArrayBuffer(res: Result)(implicit req: RequestHeader): Result =
	res.withHeaders(
	"Cross-Origin-Opener-Policy" -> "same-origin",
	"Cross-Origin-Embedder-Policy" -> (if (HTTPRequest isChrome96OrMore req) "credentialless"
	else "require-corp")
	)

Which is called when loading all of the pages that break custom board URLs:

It looks like the original reason this header was added was to enable multi-threaded WASM in firefox, though I'm not 100% sure how this is related, or if there is a workaround

Is there a way that custom board URLs could be used on all pages across the interface..? (And is there anything I could do to help if there is?)

[WandererXII]

Hey! Thanks for submitting the issues.

To get WASM engines to work we need to have:
Cross-Origin-Embedder-Policy "require-corp".
This unfortunately means that all loaded resources need to have: Cross-Origin-Resource-Policy: cross-origin.

Chrome supports credentialless instead of require-corp header (more about that here https://developer.chrome.com/blog/coep-credentialless-origin-trial/), which eliminates that need, so with chrome it should work.

It seems firefox supports it as an origin trial - mozilla/standards-positions#539 (comment). But lishogi wouldn't recognize that anyway, since we only check for chrome and there were/are some issues with it? Might need to look into it.

I might set up a proxy on heroku later tomorrow as a dirty solution. Another option would be to host all the images on lishogi...

In short, the image needs to have this header: Cross-Origin-Resource-Policy: cross-origin.

[WandererXII]

Deployed this: https://github.com/WandererXII/cors-anywhere to render.com.

Simply append the URL with your picture to https://lishogi-proxy.onrender.com/

For your image replace the link you use with this: https://lishogi-proxy.onrender.com/https://pbs.twimg.com/media/Ft0PzuiakAAcXiF?format=jpg&name=orig and it should work.

I can't guarantee that render.com will keep hosting the proxy, but for now it should work.

[Archenoth]

Oh dang! Thank you! I can confirm this works!

Though, if changing CORS stuff is hard, another thing that I sometimes do to get around things like this is to copy the base64 URI of an image so that it doesn't need to be hosted from a third party

The benefit of that is that images can't be hotlinked by third party sites, since the img src is just the image data itself, and it works without any additional setup

However, the downside of that is that those URIs can also be really long, so you'd want to enforce a reasonable length per user. Also, the TS rejects any URIs that start with anything besides https:// or //:

lishogi/ui/dasher/src/util.ts

Lines 31 to 34 in 2bd070c

	export function validateUrl(url: string): boolean {
	// modules/pref/src/main/PrefForm.scala
	return url === '' || ((url.startsWith('https://') || url.startsWith('//')) && url.length >= 10 && url.length <= 400);
	}

I'm not saying you should do this or anything, but I wanted to bring it up in case you didn't want to maintain a separate proxy altogether~ (Also, thanks again for setting that up! I really do appreciate it!)

[WandererXII]

Oh dang! Thank you! I can confirm this works!

Though, if changing CORS stuff is hard, another thing that I sometimes do to get around things like this is to copy the base64 URI of an image so that it doesn't need to be hosted from a third party

The benefit of that is that images can't be hotlinked by third party sites, since the img src is just the image data itself, and it works without any additional setup

However, the downside of that is that those URIs can also be really long, so you'd want to enforce a reasonable length per user. Also, the TS rejects any URIs that start with anything besides https:// or //:

Glad it works!

Allowing the data-url could work, but the data-url would have to be sent from the server with every html doc, which would be rather inefficient. Also storing big data-urls in the pref collection in db could deteriorate performance/memory usage.

I considered to host the images myself on a separate server, providing upload an image button to users, rather than paste a link. But for now I don't wanna get into that.
The current implementation works for chrome based browsers (https://caniuse.com/mdn-http_headers_cross-origin-embedder-policy_credentialless), the issue is firefox and safari. Hopefully firefox will soon start suporting credentialless.

[Archenoth]

This makes sense! And thanks again for the help..!

Since there really isn't anything else that can be done, I think I'll close this issue for now~