Jan 18, 2015 at 9:12 AM

I have tested to embedded NeoLua in my game engine and it works very well. The interface is reasonably simple, the performance is great (compared to other engines I have tested) but the sandboxing is none existent.

What are the plans for sandboxing support? As I see it the following three points need to be considered:
  • Configurable support for the clr
  • Better support for for modifying the global environment (removing std libraries)
  • Restricted access to reflection
Clearscript ( is a good example what I would need in terms of landboxing.

Thank you for this great scripting engine. I will try create my own to learn and hopefully I can translate my experience into adding better sandbox to this one.
Jan 18, 2015 at 12:25 PM
Edited Jan 18, 2015 at 12:27 PM

currently I plan to split the library in three parts.
  1. Neo.LuaCore -> portable Library with the compiler, LuaTable and LuaType.
  2. Neo.LuaComp -> A desktop library with the LuaGlobal an Libraries.
  3. Neo.LuaDbg -> The Debugging stuff which is already seperated.
This plan also contains a plan to cut out the clr-module. But for this, I need changes in the API. And the last time when I did this, some people were not happy about this. So, I will do this in a major release only.

What is with the current version (0.9.11) possible:
  • You can write your own LuaGlobal from scratch. Just inherit from LuaTable. I did this in my current project to. So, except of the clr modul, it is possible to do what clear script does.
  • Use the source and delete the clr-inject code.
What do you mean with restricted access to reflection?

It is always fun to create a language, but you should also have in mind to modify an existing. It is possible to add your ideas on this one.
Jan 18, 2015 at 12:53 PM
Ok. Looks like a good plan.

I managed to solve the environment issue with lua.CompileChunk("code").Run(new LuaTable(), new object[0]). Skipping usage of the GlobalTable.

I tried to remove the clr completely from the code and seems to solve my problem.

About reflection: right now it is possible to do something like this with help of an object (room in this example) I have injected:
--local file = room:GetType().BaseType.Assembly:GetType(""System.IO.File"")
--local method = file:GetMethod(""ReadAllLines"", 0, nil, 0, room.Types)
--method:Invoke(nil, room.Strings)

Clearscript has the property 'AllowReflection' on the script engine which eliminates this issue.
Jan 18, 2015 at 12:57 PM
Edited Jan 18, 2015 at 12:57 PM
Nice, good Idea I will but this on my wishlist.

It is simple I just have to filter GetType out.

Does Clearscript also filter, if an object returns a type?
public class Test
   public Type { get; }
Jan 18, 2015 at 1:05 PM
No clearscript do not filter Types in general, only GetType() it seems. But it is good enough for me.

I read in the other thread about sandboxing and an issue with const. Is that still a point of concern? If so what can be done to solve that issue?
Jan 18, 2015 at 1:18 PM
Edited Jan 18, 2015 at 5:02 PM
I will have this in my mind, may be I see something, what I can do against it.

Yes it is. Const for types I will not allowed in this mode. Good that you mention that, because I taged this conversionation to the list.
Jan 18, 2015 at 5:09 PM
I checked out to do the library as a portable library.
There is a problem windows store apps (how do I say this kindly) have a lot parts misssing.

The most important part is, the DLR part :(.

I will change my plan a little bit.
Next step:
  • fixing regex stuff
  • make clr, const, gettype optional -> sandboxing
  • make std-libraries public, that it easier to create a new environment
Did I miss something?
Jan 18, 2015 at 6:50 PM
Edited Jan 18, 2015 at 7:43 PM
Ok. Filtering out reflection would also be necessary for sandboxing. I think GetType() should be enough, but I'm not sure.
Jan 25, 2015 at 4:21 PM
I added Sandboxing functionality to the package.

Let me know what I forgot.