5 ms·

This reminds me of my multiple attempts in writing a declarative scrapper framework. In the end, I've chosen to just write the code. What I see is a crappy ad-

This reminds me of my multiple attempts in writing a declarative scrapper framework. In the end, I've chosen to just write the code. What I see is a crappy ad-hoc scripting language. I feel bad saying so, but I can only view this project as a bad solution to whatever problem you have. You could have chosen to send actual code, be it JavaScript, Python, Java or even Linux binaries, executed with limited privileges. How would that look like? AWS Lambda.

fallenshell 10y ago
Agreed.
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 ago
  The safety of a simple language is appealing.
- woah 10y ago
  I 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 ago
    The 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.

fallenshell 10y ago

Agreed.

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 ago
The safety of a simple language is appealing.
woah 10y ago
I 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 ago
  The 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.