Setting up headers in asset.RequestAsset

[Daniele Zanni]

Hi all,

I am working on a game who needs to load the users data from an external RESTfull API. I am sending GET/POSTS to a server who hosts the game logic. 

I am currently using Basic Authentication to access the API. My Tundra server/client would have to use the same when connecting to it.

So, here's my question: is there any way to set the headers inside Tundra when requiring an external resource as an asset like in this example?

// HTTP GET with query params (if you need them)

var transfer = asset.RequestAsset("http://www.yourservice.com/listobjects?myId=3&filter=test", "Binary", true);

transfer.Succeeded.connect(myHandler);

BR

Daniele Zanni

Research Scientist

MediaTeam Oulu

University of Oulu

Oulu, Finland

[Jonne Nauha]

The AssetAPI does not let you give custom headers. Also at least at some point query parameters was removed from the URL. I believe that is now fixed however. AssetAPI does support fetching binary and text based assets that are not involved in rendering etc. its still not really meant for this kind of thing. Maybe it should be however.

In the meanwhile you can get a hold of an instance of QNetworkAccessManager from the HttpAssetProvider. But seems that qt.network is blacklisted so thats not going to do you much help.

Erno: If I remember right you commited the change to make the QNAM public. Were you using it from script or just wanted to use it from C++?

Using REST APIs like what you are doing is such and important thing we should support it a lot better. Really simple APIs are usable via AssetAPI but if you need custom headers it wont help you out. On the other hand passing HTTP headers should not be a thing thats part of AssetAPI. It should not have anything provider specific in there. I wonder if HttpAssetProvider should have functions like "QNetworkReply *Post/Get(url, headersMap)", might make more sense there.

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com

--
--
http://groups.google.com/group/realxtend-dev
http://wiki.realxtend.org
http://dev.realxtend.org
---
You received this message because you are subscribed to the Google Groups "realXtend-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to realxtend-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Erno Kuusela]

On Thu, Oct 31, 2013 at 01:21:01AM +0200, Jonne Nauha wrote:
| *Erno:* If I remember right you commited the change to make the QNAM

| public. Were you using it from script or just wanted to use it from C++?

It was for a script. There's also an example script for using the auth
functionality of QNAM in the pull request:
https://github.com/realXtend/naali/pull/476

Erno

[Toni Alatalo]

Anyone up for changing the code according to the comments, i.e. move the getter to HttpAssetStorage?

I think would be good to reopen the pullreq and finish it that way.

The larger issues with asset api security are a different topic in my understanding.

Though is it now so that even with that pullreq applied it only works for local scripts? I think so because the QNetworkAccessManager type is not usable for remote code. And should not be? If it would be safe we could relax the sandbox and allow untrusted code to use it but probably it’s not.

Daniele targets running his code on a Meshmoon hosted server and those always load the code remotely, and AFAIK want to handle them as untrusted.

Qt has a browser-like XmlHttpRequest nowadays too, since 4.8 it seems(?), usable from QML: http://qt-project.org/doc/qt-4.8/declarative-xml-xmlhttprequest-xmlhttprequest-example-qml.html . I wonder if it would be possible to expose that to a QtScript env too?

Perhaps easiest way would be to add some SetHeaders slot to HttpAssetStorage? Or add headers as an optional param to an extended GetAsset there. It would then internally do the QNetworkAccessManager biz.

~Toni

[Erno Kuusela]

Yeah, in the current situation (Web client considerations + ambivalent
Qt commitment feelings of some devs) it would be best to have
a Qt-less API and something that can also be implemented
inside web browsers. XMLHttpRequest lets you set custom
headers but there may be some cross-origin restrictions
(server must indicate it allows those etc.)


Erno

[Erno Kuusela]

Oh and also, you can embed the username & password in the URL,
though that's not very secure. as in
http://username:pass...@example.com/

Erno

[Jonne Nauha]

I think there is nothing wrong with opening HTTP via qt in scripts. We already allow it via AssetAPI, adding more advanced stuff like custom headers is not going to add any security risks. Or am I missing something? As long as we limit the data your POST stuff can send is limited to the Tundra scene and other data from the APIs (cant send files from the server to your own service or something similar, as QFile is blacklisted etc.)

I would say we could open up the qt.network partly. Creating QNAM in scripts might not be the best option but registering a global one for scripts from HttpAssetProvider might be nice. At minimum we could open up QNetworkReply and QNetworkRequest. This would let you do whatever you want to the request via Qt API, hook the completion signal and just use the QNAM to send it out.

Best regards,
Jonne Nauha
Meshmoon developer at Adminotech Ltd.

www.meshmoon.com

Erno

[Erno Kuusela]

On Fri, Nov 01, 2013 at 12:52:42PM +0200, Jonne Nauha wrote:
| I think there is nothing wrong with opening HTTP via qt in scripts. We
| already allow it via AssetAPI, adding more advanced stuff like custom
| headers is not going to add any security risks. Or am I missing something?
| As long as we limit the data your POST stuff can send is limited to the
| Tundra scene and other data from the APIs (cant send files from the server
| to your own service or something similar, as QFile is blacklisted etc.)

Uncontrolled access to the Qt HTTP API is a lot more than sandboxes
typically allow. For example if you have built an "intranet"
which is not suppose to be accessible from the internet,
the script could go web crawling there and send all its findings to
the outside world.

Regardless of this, like I said in the earlier mail, we'd probably be
better off with an API that can be implemented in the Web client too.

Erno

[Erno Kuusela]

On Fri, Nov 01, 2013 at 01:00:53PM +0200, Erno Kuusela wrote:
| typically allow. For example if you have built an "intranet"
| which is not suppose to be accessible from the internet,
| the script could go web crawling there and send all its findings to
| the outside world.

Easier misuse case: you get access to file:// urls so scritps
can read all the files on the users computer.

Erno