Permission Denied on Export Base64 Encoded File From Temporary Contents

[brian_booden]

I'm trying to export an image from temp-contents using QAA.

I have managed to generate the image using 3 Call URL blocks.  These follow the workflow mentioned here: https://qlik.dev/embed/reports/reporting-api-samples/

All of the below calls are successful.

• Call 1 (Create Report) : POST: https://xxx.eu.qlikcloud.com/api/v1/reports - successful
• Call 2 (Get Report Status): GET: https://xxx.eu.qlikcloud.com/api/v1/reports/yyyy/status - successful
• Call 3(Get Image Details): GET: https://xxx.eu.qlikcloud.com:443/api/v1/temp-contents/yyyy/details - successful 

I can even access the details of the image file generated with an Output block:

 

I can also access and download the image directly with Postman using: GET: https://xxx.eu.qlikcloud.com/api/v1/temp-contents/yyyy 

I'm then trying to use Qlik Platform Operations - Export Base64 Encoded File From Temporary Contents to do the same thing and hit the following error:

I created the Oauth user already for Qlik Platform Operations - Web user, Allow Machine-to-Machine (M2M) checked, all scopes granted (for testing), Professional user allocated.

I even allocated the Oauth user all Admin user permissions and most User ones too that were not AutoML or Embedded Analytics related.

This error returns with every combo I tried so far, and I really need to be able to export the temp-contents images and export them somewhere else using QAA.

Any help you could offer would be really appreciated!

[rwunderlich]

I've found that to execute GET /temp-contents/id you have to use the same userid that created the file, otherwise status 404 and "permission denied".  An OAuth client with Admin scopes and roles won't cut it.  With the Net SDK I work around this using  "Allow M2M User Impersonation" in the OAuth def and impersonate the user that created the file. 

I'm not familiar with how you can work around this with QAA. It seems your Call URL blocks are creating the file using the logged in user and then you are trying to download using the OAuth user. I suppose you could try running the Call URL blocks using the OAuth credential, but that seems awkward as I don't see a property option for the secrets. You would have to provide a Bearer Header.

I don't know if this "Admin-can't-access temp-file" is intentional or a design flaw. 

Email me if you want to chat.

-Rob