Astrabit-ST / Luminol

An RPG Maker XP-VX Ace rewrite, written in Rust with love 💕
https://luminol.dev/
GNU General Public License v3.0
94 stars 11 forks source link

Downloading files in web builds #94

Open white-axe opened 5 months ago

white-axe commented 5 months ago

Is your feature request related to a problem? Please describe. Credentialless COEP does allow, in certain cases, downloading files from and sending POST requests to other websites on different origins without worrying about CORS. But there's a catch - whatever HTTP requests are made to other origins without CORS, JavaScript (and WebAssembly) can't access the response body, response headers or even the response status code.

In web builds, we need to make HTTP requests for two reasons: sending crash reports and downloading mkxp-based runtimes for new projects. For sending crash reports, requests with credentialless COEP are sufficient because we don't care about the response body: all we need to do is send a request containing the crash report to a server somewhere and then ignore the response. But for downloading runtimes, we can't do this because we need to read the response body in order to extract the runtime into the user's new project.

So the only way to download runtimes is still with CORS. I've already asked Ancurio to enable CORS headers on mapleshrine.eu so we can download mkxp-freebird releases, but for the other runtimes we're gonna need a different solution because GitHub doesn't set CORS headers on GitHub releases, even when downloading directly from their cloud storage buckets via the GitHub API.

Describe the solution you'd like Get Ancurio or someone else to host current and future releases of whatever runtimes we need on a server that has CORS headers enabled. The easiest way to deal with CORS is to get the server that's hosting the files to serve them with the header Access-Control-Allow-Origin: *.

Describe alternatives you've considered Use a CORS proxy as before. I'm not sure if GitHub has rate limits for downloading releases, but if it does then that's one problem. The other problem is susceptibility to man-in-the-middle attacks, but these can be mitigated by asking the people maintaining the GitHub repos to sign their future releases in GitHub Actions with PGP private keys stored as secrets on GitHub and then verifying these future releases in Luminol with the corresponding PGP public keys using rPGP or Sequoia, and, if needed, hardcoding cryptographic hashes of existing releases into Luminol.

Speak2Erase commented 5 months ago

I'd be ok hosting future releases of any rgss runtimes when I get around to remaking my website (nowaffles.com)

Speak2Erase commented 4 days ago

We can probably just host the builds on luminol.dev :p