3 ms·
I also prefer writing code to DSLs etc. Unfortunately, just writing code doesn't solve the problems mentioned here: https://github.com/JSONScript/jsonscript#pro
by epoberezkin 10y ago
I also prefer writing code to DSLs etc. Unfortunately, just writing code doesn't solve the problems mentioned here: https://github.com/JSONScript/jsonscript#problem https://github.com/JSONScript/jsonscript#problem
Sending code in some existing general purpose or scripting language makes it either difficult/inefficient to parse, or insecure (if, e.g. JavaScript or bash eval is used), or both. Limited privileges only partially protect the host and usually leave some vulnerabilities...
JSONScript is both very easy and efficient to parse (a JSON-Schema is used to evaluate the script) and it is secure because it executes the script in a "sandbox" having access only to those system resources that the host environment explicitly exposed to the interpreter.
My two main use cases are 1) scripted processing on top of existing API (implemented) and 2) proxy allowing scripted processing across multiple APIs in the same location (soon).
- tony-allan 10y agoThe safety of a simple language is appealing.
- woah 10y agoI still don't understand how this has any security advantages over just sending code. You are sending code, just shoehorning it into a serialization format.
- epoberezkin 10y agoThe difference is that general purpose programming languages usually provide full access to the host environment, they are not designed to be received from untrusted environments. You need to reduce what is allowed, and that is more likely to leave vulnerabilities, than explicitly whitelisting what methods can be called. I think that any abstraction/DSL, not JSONScript specifically, with a specialised interpreter on the server side is more likely to be secure than processing general purpose language instructions received from the client.