Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feat] Native support for use of assets unknown at build time within tauri windows. #5302

Open
matthme opened this issue Sep 29, 2022 · 2 comments

Comments

@matthme
Copy link
Contributor

matthme commented Sep 29, 2022

Describe the problem

We have the use case where we have an app store in our tauri app from which apps can be installed by the user. The assets of those apps are then installed to dedicated folders and the user should be able to open the installed app in a tauri window.
We specifically want to use tauri windows because they provide a secure channel for messages sent by those apps and the tauri backend because we can ensure in this way that messages sent by the "external" applications to tauri core cannot be intercepted/tampered with along the way (the main application is connected to a keystore protected by a password and messages from those "external" apps need to be signed by private keys stored in the keystore). Obviously we ensure that those windows can only call a very limited set of commands to tauri core (currently one single command).

Currently this doesn't seem to be natively possible without what seems like a workaround. Any window built with either WindowUrl::External("http://localhost:[port]") or WindowUrl::App([path to assets not known at build time]) does not offer IPC calls, i.e. it will raise window.__TAURI__IPC__ is not a function.

We found a workaround with which we can still achieve the above described goal (and hope this workaround remains supported as long there is no other alternative!) but it is does seem quite unnatural. They way we solve it is that we call the window builder with WindowUrl("index.html") and then use the on_web_resource_request() method to redirect requests to the corresponding folderpaths where the assets are installed, including having to guess the MIME type of the response based on the filename of the requested resource.

Describe the solution you'd like

I would like to have the possibility to explicitly allow IPC calls by windows accessing assets unknown at build time. This could for example be implemented as a method allow_external_IPC_calls() of the WindowBuilder struct or to follow the tauri conf terminology dangerous_allow_external_IPC_calls().

Alternatives considered

See workaround described above.

Additional context

No response

@FabianLars
Copy link
Member

Potentially related: #5088

@ghost
Copy link

ghost commented Dec 22, 2022

I also have a similar use case, except assets are not written to disk. Assets for the "apps" are fetched from a remote resource via an RPC call, verified and forwarded to the web view. I'm currently handling this with a local file server, but on_web_resource_request could also work for my use case. As the OP mentioned, this gap between the file (on disk or in memory) and the webview is a security concern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 📬Proposal
Development

No branches or pull requests

2 participants