LuaInterface - 如何限制对 .Net 类的访问?
我正在尝试使用 LuaInterface 2.0.3 在我的 C# 应用程序中嵌入一些 Lua 脚本功能。到目前为止,这工作得很好,但我不知道如何限制对少数指定的 .Net 类的访问。默认情况下,所有.Net库都可以通过“luanet”直接访问,并且Lua脚本可以自由打开新窗口或访问文件系统。
例如,这个 Lua 脚本将打开一个新窗口:
Form = luanet.System.Windows.Forms.Form
mainForm = Form()
mainForm:ShowDialog()
脚本编写自由固然很棒,但这可能会干扰托管应用程序,并且会产生一些我不太喜欢的与安全相关的影响。有什么办法可以禁用这个吗?
I'm trying to embed some Lua scripting functionality in my C# app by using LuaInterface 2.0.3. This is working just fine so far, but I can't figure out how to restrict access to only few specified .Net classes. By default, all .Net libraries are directly accessible through "luanet" and Lua scripts are free to open new windows or access the file system.
e.g. this Lua script will open a new Window:
Form = luanet.System.Windows.Forms.Form
mainForm = Form()
mainForm:ShowDialog()
Freedom of scripting is great and all, but this is likely to interfere with the hosting app and has some security-related implications I'm not too fond of. Is there any way to disable this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您也可以相反地执行此操作,首先删除 LuaInterface 的全局实例和存储实例,然后通过本地引用完成所有工作(所有代码都在 block 可以使用):(
您可以避免上面的三步名称保存舞蹈(
local luainterface=luanet; luanet=nil; local luanet=luainterface
) 通过直接本地化到luanet
然后通过对全局表的_G
引用删除全局:我只是选择不视个人喜好而定。)
You could also do this in reverse, removing the global and stored instances of LuaInterface first and then doing all the work through a local reference (which all code in the rest of the block can use):
(You can avoid the three-step name-preservation dance above (
local luainterface=luanet; luanet=nil; local luanet=luainterface
) by localizing directly toluanet
and then deleting the global through the_G
reference to the global table:I just chose not to as a matter of personal preference.)
我不太确定你到底会如何做,但第一步应该是将其托管在一个额外的 应用程序域。通过这个额外的应用程序域,您可以精细地控制哪些模块可以使用,哪些不能使用,但是,它将增加额外的工作以在主程序和脚本之间移动数据。
AssemblyLoad
/AssemblyResolve
事件应该是您的第一站。I'm not really sure about how exactly you would go about it, but the first step should be hosting it in an extra AppDomain. With that extra appdomain, you have granular control of what modules can be used and which can't, however, it will add extra work to get data moved between your main program and the script.
The
AssemblyLoad
/AssemblyResolve
events should be your first stop.