4 ms·

Fairly certain you don't want to be throwing `eval` in your code. I'm also building a workflow engine on the side, but don't want to see you run into security

by tonyhb 6y ago

Fairly certain you don't want to be throwing `eval` in your code. I'm also building a workflow engine on the side, but don't want to see you run into security issues :) Look into the realms TC39 proposal, the SES TC39 proposal, or running (no joke) a lightweight ES6 environment in webassembly to eval your code. https://github.com/tc39/proposal-realms/#ecmascript-spec-proposal-for-realms-api https://github.com/tc39/proposal-realms/#ecmascript-spec-pro... https://github.com/tc39/proposal-ses https://github.com/tc39/proposal-ses https://github.com/justjake/quickjs-emscripten https://github.com/justjake/quickjs-emscripten

flowerlad 6y ago
> you don't want to be throwing `eval` in your code Unless you have generated the JS code yourself, in which case it is safe. What kind of perf are you getting with QuickJS? If you have to evaluate an expression 10,000 times is QuickJS at least half as quick as eval?
- tonyhb 6y ago
  True. Though I'd err on the side of caution in case someone in the team makes a PR to enable templating or user data somewhere that uses this code under the hood. Currently working in healthcare, so it's safest to work under the assumption of "don't introduce anything unsafe if possible, even if we know data is sanitized by us". Just in case one day that data is _not_ supplied by us. RE. perf, I initially used Realms and it was fine. Right now I'm using wasm for templating and cuelang parsing - the speed is _good enough_ for the current UI, though I haven't really done strict performance testing yet, being honest :(
hetunandu 6y ago
Author here. We have experimented with Realms in the past and had a working version for some time. Also did some POC with quickjs. In both scenarios, we saw performance degrade a lot.. So our current eval is run actually in the web worker so we take extra precautions to avoid leaking any problem some browser api inside the eval context. I like the idea of having a wasm eval environment as well, will experiment with that soon. Thanks for the tips :)
schwartzworld 6y ago
What's the downside of calling eval in the client?

by tonyhb 6y ago

flowerlad 6y ago

> you don't want to be throwing `eval` in your code Unless you have generated the JS code yourself, in which case it is safe. What kind of perf are you getting with QuickJS? If you have to evaluate an expression 10,000 times is QuickJS at least half as quick as eval?

tonyhb 6y ago
True. Though I'd err on the side of caution in case someone in the team makes a PR to enable templating or user data somewhere that uses this code under the hood. Currently working in healthcare, so it's safest to work under the assumption of "don't introduce anything unsafe if possible, even if we know data is sanitized by us". Just in case one day that data is _not_ supplied by us. RE. perf, I initially used Realms and it was fine. Right now I'm using wasm for templating and cuelang parsing - the speed is _good enough_ for the current UI, though I haven't really done strict performance testing yet, being honest :(

hetunandu 6y ago

Author here. We have experimented with Realms in the past and had a working version for some time. Also did some POC with quickjs. In both scenarios, we saw performance degrade a lot.. So our current eval is run actually in the web worker so we take extra precautions to avoid leaking any problem some browser api inside the eval context. I like the idea of having a wasm eval environment as well, will experiment with that soon. Thanks for the tips :)

schwartzworld 6y ago

What's the downside of calling eval in the client?