Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
master_t
Partner - Creator II
Partner - Creator II

Qlik SaaS: session token / identity

I have an application that uses the .NET SDK to connect to a Qlik Cloud instance and make a series of selections, like this:

var cloudLocation = QcsLocation.FromUri(uri);
var sessionToken = SessionToken.Custom("my-session-token");
var app = cloudLocation.App("my-app-id", sessionToken);
//... make selections, set variables, etc...

As you can see, I'm using a custom session token, because I then I want to be able to launch a browser and recover that exact session, by using the "identity" parameter in the URL, like this:

https://my-tenant-url/sense/app/my-app-id/sheet/sheet-id/state/analysis/identity/my-session-token

This worked on Qlik Sense Enterprise, I've been using it for years in this application. However,  it doesn't seem to work at all with Qlik Cloud, if I go to the URL it looks like the selections I've made with the SDK are not there, like they're two completely different sessions. 

Am I doing something wrong? Is this not supported anymore in Qlik Cloud? Is there a workaround to sync the SDK and Browser session??

 

Labels (3)
2 Solutions

Accepted Solutions
Øystein_Kolsrud
Employee
Employee

This part of the connection flow is handled differently in QCS compared to QSEfW. The "identity" part in the URL used for defining an engine session identifier in QSEfW has in QCS been replaced by a header in the request you send when accessing the system. The header should be of the following form:

 

X-Qlik-Session: my-session-token

 

If you inject this header in your browser, then the code you use in the .NET SDK should work just fine.

View solution in original post

master_t
Partner - Creator II
Partner - Creator II
Author

Thanks for your reply. At first it didn't seem to work, but I think you made a typo: using X-Qlik-Session it works!

Thank you for your support

View solution in original post

4 Replies
Øystein_Kolsrud
Employee
Employee

This part of the connection flow is handled differently in QCS compared to QSEfW. The "identity" part in the URL used for defining an engine session identifier in QSEfW has in QCS been replaced by a header in the request you send when accessing the system. The header should be of the following form:

 

X-Qlik-Session: my-session-token

 

If you inject this header in your browser, then the code you use in the .NET SDK should work just fine.

master_t
Partner - Creator II
Partner - Creator II
Author

Thanks for your reply. At first it didn't seem to work, but I think you made a typo: using X-Qlik-Session it works!

Thank you for your support

Øystein_Kolsrud
Employee
Employee

Yes, you're absolutely right!  It should of course be "X-Qlik-Session" not "Q-Qlik-Session". I'll edit the reply...

master_t
Partner - Creator II
Partner - Creator II
Author

Has anything changed on this front since this thread was created?

I see in the Qlik SaaS documentation that using the "identity" parameter should be supported:

https://qlik.dev/apis/javascript/single-integrations

but I wasn't able to make it work no matter what I tried.

The trick of injecting the X-Qlik-Session header still works, but it is very annoying because it is not enough to inject it into the initial page request, it must also be injected directly into the WebSocket connection that Qlik Sense creates upon connecting to the engine.

In my use case, for example, I have a desktop application that is supposed to connect to the Qlik SaaS engine via the .NET SDK, make some selections and then show the user some specific objects inside a browser window. However, I couldn't find any web automation libraries that allow you to inject a header in a websocket, even advanced ones like Puppeteer do not support this. The only solution I found to make it work reliably is to run the connection through a proxy software that injects the header everywhere, but it seems a bit overkill... is there a specific reason why we can't just add the header to the initial request to make this work? Seems wierdly convoluted...