Hi, I think sandbox support would be a really nice feature to have for the Loader component in QtQuick2. I've implemented a SandBoxLoader just to prove the concept using QtQuick1. It's in the following branch:
http://gitorious.org/qmlarsenal/qmlarsenal/commits/sandboxloader The main goal is to avoid loaded items to read or change data outside its own scope. This feature is mandatory when you have to load 3rd party plugins in your application in a safe manner. Normally, loaded items have full access to top level properties and elements, leading to a security breach. One can change a QML plugin to steal information or basically make a mess in the application logic/design. Follows an usage example: Item { property string abc: "" SandBoxLoader { source: "FooBar.qml" } } // FooBar.qml Item { Component.onCompleted: print(abc) // that will result in ReferenceError } I've also hacked the SandBoxLoader parent property to avoid parent hijacking. That will prevent an user to walk in the parent hierarchy, in the attempt to change or access 'hidden' information, like the following: // FooBar.qml Item { Component.onCompleted: print(parent.parent["abc"]) // this will not work too } I have some questions regarding QDeclarativeEngine though. The first one is if it's safe to create multiple instances of QDeclarativeEngine in a application? There are some internal limitations that could lead to unexpected behaviors? The reason I ask that, it's because each SandBoxLoader creates its own engine in order to avoid sharing the same root context of the main engine. The second question is related to QDeclarativeEngine::setImportPathList method; I would like to avoid the loaded item from importing system plugins, but reseting the importPathList of the internal engine does not prevent that. Is it the right way to handle this? Does the engine cache loaded models in a singleton element? Cheers, Adriano _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
