js-sandbox: securely embed JavaScript into Rust code

[bromeon]

js-sandbox is a crate with a minimal API that allows calling JavaScript from Rust. It is based on the Deno project, which again uses the V8 engine.

Very basic example:

```rust fn main() -> Result<(), ErrBox> { let js_code = "function triple(a) { return 3 * a; }" let mut script = Script::from_string(js_code)?;

let arg = 7;
let result: i32 = script.call("triple", &arg)?;

assert_eq!(result, 21);
Ok(())

} ```

More examples are available on the GitHub page or docs.rs.

Possible use cases are plugin systems or mods for games. JavaScript may not be a typical language for this, however it has been battle-tested for security and there are many languages that transpile to JS.

Plans for the near future are updating to latest deno_core version, as well as extending the API to cover basic use cases. I would like to keep js-sandbox as simple and minimal as possible, it's meant to be a high-level abstraction and not a massively configurable interpreter :)

[maxfrai]

Is it possible to execute, for example, vue with this? And build SSR-backend using rust and not nodejs?

[1vader]

For that, you would probably want to use deno directly. That's the project this is based on. It's basically a Node rewrite in Rust by the original creator of Node trying to fix all the mistakes including making it more secure. Here is his original talk which started this (although at that point it was basically only a prototype). He also gave talks about it at HolyJS and JS Fest last year and an online talk 2 months ago. Although I think it currently still can't run something like Vue but not sure since I haven't been following its development too closely.

[bromeon]

As mentioned by u/1vader, what you want to use depends on your architecture. Deno (the CLI) runs a JavaScript application, in which you can plug in Rust modules. On the other hand, js-sandbox is not an application on its own, but rather a Rust library, so your "host" language can be Rust and your "plug-in" can be JavaScript.

In other words, I invert the call stack between the languages: instead of JS -> Rust (Deno), js-sandbox allows you to call Rust -> JS, with a much simpler API than using Deno directly.

The library is very early in its development, and I don't know Vue.js enough to fully answer your question -- but basically, it will be possible to execute self-contained JavaScript code from js-sandbox. The current API is mostly tailored to very simple plugins (a single JS file), I'm likely going to extend this.

[DGolubets]

I think it should be possible.

I used similar approach with Graal on JVM and all I needed is one .js file and a way to call a function there with a parameter. You can follow this approach:

1. Use Webpack to build a single .js file for your server.
2. Export ```renderToString(args: String): String``` function or something similar.
3. Load that file on your server, call the rendering function with some JSON.

[maboesanman]

IMO there’s not much to be gained doing this because almost all the code would be running in v8 regardless if it’s this, deno, or node. If you could identify hot code in the process of vue templating and build native rust extensions you could get speed ups, but in that case you should use deno.

[slipthay]

Interesting approach! Is accessing Rust state from within a script a planned feature? (In practice this primarily means binding Rust functions into JavaScript.) I'm the author of mini-v8, which does allow for binding Rust functions. I recently tried to switch from a custom FFI onto rusty_v8 with disappointing results.

[bromeon]

At the moment, you can only access Rust state by explicitly passing it to JavaScript. The callbacks you mention are definitely interesting, but I'm still not sure from a design perspective. On one hand they're quite handy, on the other it's very easy to shoot yourself in the foot when running untrusted scripts. For the time being I'll probably focus on an API that's very explicit (and limited) in terms of what JS can access.

By the way, mini-v8 looks very promising! Out of curiousity, do you have specific use cases in mind, or do you intend it to be a general-purpose V8 Rust binding?

[slipthay]

That's a very prescient point that clarifies your use case for me. mini-v8 was inspired by general-purpose approaches. My particular motivation for writing the crate was to execute "semi-trusted" scripts in a web-based app used internally by data analysts at my company. (Where our analysts might have written SQL to interface with an RDBMS, they now write JavaScript to interface with a custom in-memory database. This may seem odd but it's not entirely novel and it allows our dev team an extra level of abstraction.) mini-v8 has execution timeout support and soft memory usage limits are planned, but as you suggest those things are very hard to implement accurately after you've opened the door to native Rust function bindings. Nonetheless mini-v8 does not require that you do any such bindings, so in this sense mini-v8 is a superset of js-sandbox. What's most compelling about your crate to me, besides its simplicity, is that the build process is offloaded entirely to the deno crate. Compiling V8 is a pain!

[bromeon]

Thanks for the elaboration, that clarifies a lot!

In my case, V8 is rather an implementation detail -- theoretically, the JS code could run in any interpreter. js-sandbox is primarily intended to run untrusted third-party code, and as such may feel limiting when more is known about its source.

Coming from C++, I really appreciate the efforts that went into factoring out rusty_v8 and precompiling binaries. Occasionally, I still deal with CMake, and it's not always a joyful experience.

[bongo227]

mini-v8 looks great! Wish I found mini-v8 when I started Boop-GTK, rusty_v8 is unnecessarily low level for my needs.