LuaInterface - 如何限制对 .Net 类的访问?

发布于 2024-11-10 02:57:54 字数 368 浏览 1 评论 0原文

我正在尝试使用 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

牵强ㄟ 2024-11-17 02:57:55
--make a table for all the classes you want to expose
safeClasses = {}
--store all the ones you want
safeClasses.Form = luanet.System.Windows.Forms.Form
--etc...

--remove access to LuaInterface
luanet = nil
package.loaded.luanet = nil
--prevent future packages from being loaded
require = nil
package.loadlib = nil

您也可以相反地执行此操作,首先删除 LuaInterface 的全局实例和存储实例,然后通过本地引用完成所有工作(所有代码都在 block 可以使用):(

--get a local reference to LuaInterface without clobbering the name
local luainterface = luanet

--delete the global reference to it
luanet = nil

--also delete it from the package store and disable package loading
package.loaded.luanet = nil
require = nil
package.loadlib = nil

--put luanet back locally at its original name (for convenience)
local luanet = luainterface 

--make a table for all the classes you want to expose
safeClasses = {}
--store all the ones you want
safeClasses.Form = luanet.System.Windows.Forms.Form
--etc...

您可以避免上面的三步名称保存舞蹈(local luainterface=luanet; luanet=nil; local luanet=luainterface) 通过直接本地化到 luanet 然后通过对全局表的 _G 引用删除全局:

local luanet=_G.luanet
_G.luanet = nil

我只是选择不视个人喜好而定。)

--make a table for all the classes you want to expose
safeClasses = {}
--store all the ones you want
safeClasses.Form = luanet.System.Windows.Forms.Form
--etc...

--remove access to LuaInterface
luanet = nil
package.loaded.luanet = nil
--prevent future packages from being loaded
require = nil
package.loadlib = nil

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):

--get a local reference to LuaInterface without clobbering the name
local luainterface = luanet

--delete the global reference to it
luanet = nil

--also delete it from the package store and disable package loading
package.loaded.luanet = nil
require = nil
package.loadlib = nil

--put luanet back locally at its original name (for convenience)
local luanet = luainterface 

--make a table for all the classes you want to expose
safeClasses = {}
--store all the ones you want
safeClasses.Form = luanet.System.Windows.Forms.Form
--etc...

(You can avoid the three-step name-preservation dance above (local luainterface=luanet; luanet=nil; local luanet=luainterface) by localizing directly to luanet and then deleting the global through the _G reference to the global table:

local luanet=_G.luanet
_G.luanet = nil

I just chose not to as a matter of personal preference.)

夕嗳→ 2024-11-17 02:57:55

我不太确定你到底会如何做,但第一步应该是将其托管在一个额外的 应用程序域。通过这个额外的应用程序域,您可以精细地控制哪些模块可以使用,哪些不能使用,但是,它将增加额外的工作以在主程序和脚本之间移动数据。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文