[feat] Allow either CORS, or tauri:// custom domain support

[BlobTheKat]

Describe the problem

Currently, it is impossible to have a sandboxed iframe whose resources are in the dist folder

E.g index.html trying to sandbox an iframe to iframe/index.html

The reason is that if the iframe tries to load a local resource, it does not pass CORS checks

E.g iframe/index.html loads script.js, fails with CORS error

Describe the solution you'd like

The most obvious workaround is to allow setting CORS headers to the dev server and production "server" (asset loader) If that were to be implemented, it would also make sense to allow setting other important headers too (e.g Cache-Control)

Another solution would be to allow other domains than just localhost This already works on the dev server, but it would be immesurably helpful to also allow other domains (e.g tauri://iframe.localhost or tauri://usercontent.localhost:100), which would have their own separate localStorage and be treated as a different origin in general Something I would really like to see is the ability to map different domains to different dist folders (e.g tauri://localhost maps to main ../dist, but we could also, for example, map tauri://other.component to ../component2

Workarounds

At the moment, there is a workaround specifically for iframes, but it is very limited and works by abusing a bug where the request domain isn't checked properly. Specifically, say we make a request tauri://localhost.other/abc. The protocol handler strips the expected tauri://localhost, which would normally leave a path like /abc/def, where the first character / is stripped. In this case, the leftover path is actually .other/abc, and then the "/" is stripped, despite not actually being checked if it is really a /. Ultimately, the path looks like other/abc and that asset is loaded This bug essentially maps tauri://localhost.* to ../dist/* I am not asking that this bug be fixed (at least not yet, since it is the only workaround), but that first a solution to the above iframe problem is provided, while we use this workaround.

One last thing to consider, I haven't done any testing on windows, and I know that protocols are handled differently on windows. Please let me know below!

[cardo-podcast]

any news on this?

[BlobTheKat]

any news on this?

seems like their focus is elsewhere

[Moeweb647252]

any news on this?

[thorbetz]

Is this issues in the near future?

[FabianLars]

No, there's no plans in the (very busy and small team) to work on this ourselves.

The most obvious workaround is to allow setting CORS headers to the dev server and production "server" (asset loader) If that were to be implemented, it would also make sense to allow setting other important headers too (e.g Cache-Control)

Nowadays there's a way to set headers https://v2.tauri.app/reference/config/#headerconfig but i'm not sure if that's enough for this use-case here.

Another solution would be to allow other domains than just localhost This already works on the dev server, but it would be immesurably helpful to also allow other domains (e.g tauri://iframe.localhost or tauri://usercontent.localhost:100), which would have their own separate localStorage and be treated as a different origin in general

In the meantime you could use the existing custom protocol support (changes the tauri:// part instead of the localhost part) via https://docs.rs/tauri/latest/tauri/struct.Builder.html#method.register_asynchronous_uri_scheme_protocol (or its sync variant above in the docs) which is pretty much what powers the default tauri protocol as well.