You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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]")
orWindowUrl::App([path to assets not known at build time])
does not offer IPC calls, i.e. it will raisewindow.__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 theon_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 theWindowBuilder
struct or to follow the tauri conf terminologydangerous_allow_external_IPC_calls()
.Alternatives considered
See workaround described above.
Additional context
No response
The text was updated successfully, but these errors were encountered: