假設我有一個以Java編寫的現有應用程序，我希望添加腳本支持。對於Groovy來說這是相當簡單的（對於任何Iron範圍的動態語言，在.Net中也是如此。將腳本安全性添加到應用程序
儘管添加支持並不重要，但它引發了大量有關腳本執行和安全性的問題 - 以及如何實現該安全性。
有沒有人遇到過任何有趣的文章/論文，或者有任何他們想分享的見解？特別是我會對像執行上下文，腳本身份驗證，腳本簽名以及這些行中的事情這樣的架構事物非常感興趣......您知道，這種東西阻止用戶運行任意腳本，他們只是碰巧下載哪些腳本搞砸了他們的整個應用程序，同時仍然允許腳本變得有用和靈活。
快速編輯
我所提到的簽名和認證爲不同的實體，因爲我看到他們安全的不同方面。
例如，作爲應用程序的開發者/供應商，我分發了一個簽名的腳本。這個腳本在設計上是合法的「數據破壞性」。就像它的本質一樣，它只能由管理員運行，因此絕大多數用戶/系統進程不應該能夠運行它。在我看來，基於腳本執行的操作和誰在運行該腳本，需要某種安全/身份驗證上下文。
您可以查看安全文檔： http://groovy.codehaus.org/Security 基本上，您可以使用通常的Java安全管理器。
除此之外，還有一個示例應用程序顯示瞭如何在編譯時通過分析AST（抽象語法樹）來反編譯代碼，以便您可以允許/禁止某些代碼構造等。一個算術外殼展示了這個動作： http://svn.groovy.codehaus.org/browse/groovy/trunk/groovy/groovy-core/src/examples/groovyShell
腳本簽約
從概念上講，這只是把手伸進你的密碼工具箱，使用現有的工具。讓人們簽署他們的代碼，在下載時驗證簽名，並檢查簽名的始發者是否可信。
困難的（呃）問題是什麼讓人值得信任，誰會選擇這個問題。除非你的用戶是技術人員，否則他們不想考慮這一點，所以他們不會制定好的政策。另一方面，你可能會有讓用戶引入信任[除非你想去一個iPhone AppStore風格的圍牆花園，這聽起來不像]。
腳本認證
這個怎麼樣從簽署有什麼不同？或者，你的問題就是：「我在這裏應該考慮什麼概念」？
真正的問題當然是：你想讓你的用戶得到什麼保護？它只是在途修改，還是你也想對腳本的行爲做出保證？一些例子可能是：腳本無法訪問文件系統，腳本只能訪問文件系統的特定子樹，腳本無法訪問網絡等。
我認爲這可能[工作量]爲腳本如何訪問外部世界提供了一些保證，如果這些腳本是在haskell中完成的，並且IO monad被分解爲更小的碎片。或者，如果你的腳本運行在他們自己的不透明monad中，並且可以訪問有限的IO部分。確保刪除對不安全功能的訪問。
您可能還想了解進入Java（小程序）安全模型的注意事項。
我希望這能給你一些想法。
我認爲重用java小程序安全模型看起來是一個好的開始。 – Chii 2009-01-25 10:32:54