Change CORS to allow profile downloading

[06000208]

Hello thunderstore team, I have a request regarding your api and cdns.

Per #7, the CORS headers set on the api route https://thunderstore.io/api/experimental/legacyprofile/get/{key}, as well as the cdn with routes like https://gcdn.thunderstore.io/live/modpacks/legacyprofile/{key}, do not allow api use from non-thunderstore domains.

This presents a barrier to my project, a frontend web app I've made to view the mod list of an r2modman/thunderstore profile code without downloading the individual mods, which r2modman and thunderstore mod manager currently require you to do. This saves thunderstore and myself bandwidth and time, because if I'm not interested in playing a profile judging by the mod list, I won't have to download mods unnecessarily.

My main reason for writing this as a frontend web app was to enable sharing mod lists by query string in the url, such as https://example.com/r2modman-profile-viewer?code=038d1.... If I made it a desktop app using electron, nwjs, or similar, I could simply ignore CORS, but it would make these share links too self defeating, as users would have to download the app.

It's possible to use a proxy or server side to circumvent the same origin policy; but I would really prefer to avoid doing this:

• I consider it bad practice to circumvent security measures, as well as being potentially against thunderstore's wishes
• Would make my project dependant on the host's uptime, speed, and bandwidth
• Shares profile codes with the host, which I'm considering to be at least kind of privileged information
• Consolidates all profile requests from the host's IP rather than allowing requests to come decentralized from user's own IPs
• Server sides cost money and bandwidth, where the cost of hosting a static web app is ate by github

Here are some screenshots of my functional demo, including validating profile codes and caching profile data in local storage to avoid unnecessary requests, and parsing of the base64 zip file data:

Screenshots of the web app (Click to expand)

Last, but not least, the current CORS headers has the side effect of stopping same origin policy compliant implementations from using your api or cdn, such as deno's fetch() api, I believe. I may be wrong on this point, as I haven't used deno in a while.

That'll be all, thank you for your time, as well as what you all are doing for modding communities.

[MythicManiac]

Hey, as of now I'm not sure what are we going to do about the CORS policies specifically, but we'd certainly be happy to facilitate some way to make your use case possible.

I do want to note that we've been hoping to eventually have profiles & their content listed on the website directly in some fashion, but this is also unlikely to happen any time soon. A community built solution in the meanwhile would go a long way in improving the situation for sure.

The easiest way forward would most likely be for us to simply whitelist the specific domain you plan on hosting the site on in our CORS policies (saves the trouble of thinking through wider CORS changes), but there might be other options too so I'd suggest you send me a DM on Discord and we can figure out the specifics there!

[06000208]

Alright, messaged on discord yesterday, same username as here and display name "colorful wonder"