Handle LFE bytes in REST handler

[oubiwann]

Task:

• Receive bytes in POST route
• Convert bytes to string
• Build list of all mod:func occurrences in string
• If any of those are not in the allowed/safe list of mod:funcs, reject the entire payload out of hand, returning an appropriate HTTP error and JSON error payload

Depends upon:

• Convert existing REST server to Nova #21

[yurrriq]

How tricky would it be to redefine the LFE code that parses funcalls to check a white/blacklist? i.e.

• User types code and code is sent over the wire to interpreter as string
• Interpreter parses the string
• Eval parsed string, checking each funcall against the list
  • If allowed, pass to actual funcall handler
  • Otherwise, return 🚫

[oubiwann]

This discussion should probably be in ticket #4.

This ticket is just for providing the functionality of string parsing for use by the YAWS appmod/REST service. I should have put more detail in the ticket description.

[oubiwann]

Alight, I've made a very first pass at this. Still not sure about going the LFE shell process route or the ENV management route (#14). I'm leaning towards ENV now ...

Anyway, here's a screenie showing some basic evaluation happening in the REST server and then getting passed up to the JS in the browser:

[rvirding]

These three issues, #8 #9 and #14, are really three sides of the same problem so I will write once and copy and then we will see where the discussion goes.

• It would be quite easy to open the LFE shell and provide externally callable functions to process commands. run_string and run_script almost do that today.
• You would then write a new top-loop using these functions.
• This would not solve the problem of input/output when processing the commands, they by default send to/read from standard_io.

An easier way might then be to use the existing shell but to reset where the shell's, and the processes it starts, standard_io to control input/output. You then automatically handle all io in the commands. This is actually very easy to do, an example*:

http://www.geekherocomic.com/2008/11/12/real-programmers-dont-write-documentation/

This can also make the shell manager easier. The real question is then how we want to interface the "shell".

• This is also a good example of how versatile the io system really is. :-)

[oubiwann]

The command results coming back into JavaScript from the REST server that executes the LFE code are getting converted to JSON before they do. There's nothing yet that deserializes data structures. For instance, calling (init:get_arguments) in the browser REPL returns [object Object] (but the debug output on the server shows the json that it actually is).

This is one of many things that will have to be addressed by the JS command/results parsing code. I'll update the main description with tasks as I identity them.

[oubiwann]

Addressed this with the following change:

-         (json (ljson:encode `#(result ,result))))
+         (str-result (lists:flatten (lfe_io:fwrite1 "~p~n" `(,result))))
+         (json (ljson:encode `#(result ,(list_to_binary str-result)))))

[oubiwann]

I think we're just going to receive bytes ... let me update the title and the description.