Question about QtWebKit security origins

mitya57

Hi,

I am developer of a Markdown editor that uses QtWebKit to show file previews. It uses the following code to set HTML on the web view:

webView.setHtml(html, QUrl::fromLocalFile(filePath));

Here, filePath is an absolute path to the Markdown file being edited. Passing it is needed to make sure QtWebKit can show images given by their relative paths.

After this call the security context has file as its scheme, so according to the documentation this is a “local” content, and thus should be unable to access remote URLs (because QWebSettings::LocalContentCanAccessRemoteUrls attribute is set to false by default).

However, if I put a script that tries to do an XMLHttpRequest to my remote server, I see in the server logs that the request succeeds.

Why does that happen? Is there any way to disallow remote requests? (I would prefer a solution that disallows any requests from JS code, loading an external resource from HTML code is fine for me).

What I have tried:

If I do not pass the url to setHtml(), then the security origin scheme is an empty string, but remote HTTP requests no longer succeed.

As I have already said, this is not an option for me, and I have tried this just for testing purposes.
If I save the HTML to a file and then load that file using
```
webView.load(QUrl::fromLocalFile(htmlFilePath));
```
Then the first time, scheme is empty (and requests to remote server do not succeed). But if I do that call twice, then the second time the scheme becomes 'file', and remote requests start succeeding again.

This behaviour seems strange to me, probably it is a bug in QtWebKit.

I am using Qt 5.4.1 from Debian GNU/Linux experimental repositories.
Unfortunately switching to QtWebEngine is not yet an option for me.

mitya57

I have now filed https://bugreports.qt.io/browse/QTBUG-45556 about this issue.

coquetangler

I'm surprised that nobody replied to this as its a showstopper in Qt 5.4. What worked perfectly well in Qt 4.8 does not anymore. One solution to this issue is to build a small HTTP server into your editor that listens on a known port and can serve the files for you. Its the only way I found to get around these changes that were introduced.

SGaist

@coquetangler
Hi, this forum is community driven so it's probably something that none of the users here could answer. In any case, you can follow the progress of the fix on the bug report and gerrit patch (see last post on the bug)