Is there a solution for importing local resources?

[unbyte]

I have written many desktop programs using Tauri. Thank you for your work!

Recently I came across a scenario that needs to be able to dynamically load local JS files at runtime, I have tried to use a custom schema protocol to load but failed, due to CORS. So I wonder if there is a solution to solve it?

Cross origin requests are only supported for protocol schemes: http, data, chrome-extension, edge, https, chrome-untrusted.

Or how can I add custom middlewares to handle assets loading on http://tauri.localhost?

To avoid causing XY problems: I want to implement a dynamically loaded plugin (written in JS) mechanism.

🙏

[nothingismagick]

If I may be so bold, this is REALLY asking for your app to get pwned. At any rate, one solution would be to acquire the path in rust, read the file in rust, then eval it in the webview by rust. But again, you basically open all the gates to XSS which can (will probably) have massive implications on your security. I cannot recommend this pattern.

[unbyte]

I thought someone would have implemented plugin systems in Tauri 😣

In fact, I can tolerate the possibility of unsafe code execution (because my scenario will strictly control the source of plugins), but eval seems dirty.

how can I add custom middlewares to handle assets loading on http://tauri.localhost?

Is HTTP middleware mechanism possible?

[amrbashir]

Registering a custom url scheme should do what you want, please join our discord so we can help triage this further and quicker.

[frnco]

In fact, I can tolerate the possibility of unsafe code execution (because my scenario will strictly control the source of plugins), but eval seems dirty.

I've used eval for plenty of stuff, but it's never easy to decide to use it, especially if anyone, ANYONE other than you will be able to pass something to that eval. When I used it, it was mostly because String interpolation sucks in some languages and when I make hac-ish stuff that only I will use I mix whatever languages come to mind for each part of the task (i.e., while trying to scrape some data or whatever from a client's old site to use in the new site, I write a small tool that takes a JSON file containing CSS selectors and what field to get the data from for that selector, then another client appears and for that I need to parse the prices, removing the "US$" etc., so I just change the part that loads the data and replace the conditions for src, href innerHtml etc with an eval and I'm done with that. Yeah awful, still got the job done, though it's been years since I've last done awful things like that).

A plugin system that actually uses Javascript is actually very, VERY powerful. It actually gives the person writing the plugin complete control over all the data, and the whole ui, of your app. There's a reason so many plugin systems use DSLs and limit the plugin abilities to sandboxes, and giving this much power to plugins means any vulnerability in any plugin can potentially compromise everything in the whole system, so I urge you to take another look, maybe another dozen looks, at @nothingismagick saying it's not recommended, because although there's an off-chance that this is actually the best solution for you, it's much more likely that you're overlooking something.

If you're absolutely sure this is what you want, then I'd probably use tauri commands to load the plugins' code from javascript files or whatever (https://tauri.studio/en/docs/guides/command), basically a rust function that would return the javascript code as a string, and call that function from the Javascript using invoke (The previous link also has an example of that). Then you can either append a <script> tag on the HTML or eval or whatever. Still, I'd probably have the Rust code do all kinds of checks and make it very strict about what can and can't be loaded. Loading from https is always safer, maybe having hashes of the plugin's code and checking them on the Rust code before returning the Javascript, whatever you can think of to prevent anyone with malicious intentions from being able to get their code into your app, no matter whether they change some file in the user's computer or do a man-in-the-middle-attack to replace the plugin code with something else or whatever you can even dream that might happen if a Lord Sith used The Force to turn the universe against you. Or something worse than that if you can think of something. Because once your application is out in the world, someone will figure out each and every way to screw it up.

Good luck with the plugin system, and if you decide it's a better idea to limit the plugins, there are many ways to do that, depending on what you actually need the plugins to do. Even something as simple as having a sandboxed environment that runs the plugin's code and lets it access whatever data subset you choose, but forbids it from accessing any other data, system functions etc., could be a reasonable way to do that. I'm pretty sure many people have dealt with that, so there are probably libraries and stuff to deal with that kinda stuff (From the top of my head, we have sandboxes in browsers, there's docker, there are chroots and things like that on Linux, it seems quite likely that at least a few people have published libraries to deal with that).

[vdvman1]

One option would be to have the plugins be compiled to webassembly, that way it is automatically sandboxed and can only run functions you actually give it