I started to work with .net sdk a month ago,
now i have a problem that i can't solve, my goal is to replicate the web-browser's call on the qlik sense's printing service on the .Net SDK (.net Core),
so i need the session token on the header (for example: "Cookie:X-Qlik-Session=098d42b5-8b68-4a5f-b079-9ee569fec211").
I'm able to retrieve this token from the follow call using the the latest Qlik SDK(v13.14.0) for.Net Framework v4.5.2,
the working code:
ILocation location = Qlik.Engine.Location.FromUri(uri);
var user = "myuserid";
var pass = "mypassword";
location.AsNtlmUserViaProxy(proxyUsesSsl: uri.Scheme.Equals(Uri.UriSchemeHttps), loginCredentials: new System.Net.NetworkCredential(user, pass));
using (IHub hub = location.Hub(noVersionCheck: true))
String SessionCookie = location.SessionCookie;
Console.WriteLine("My session cookie is: " + SessionCookie);
Now, i need this SessionCookie valorized correctly into the .NetCore v2.1 framework Environment, and using the same code above on the same version of Qlik SDK, it gave me a null value.
Someone can explain me the reason why, or suggest a solution?
Solved! Go to Solution.
This is a bug in the .NET Core implementation of the connection mechanism. Thank you very much for reporting this and bringing it to our attention. We will report back to this thread when there is a fix available.
A workaround for you might be to acquire the ticket up front and connect using that ticket using the AsExistingSessionViaProxy configuration. There is an example that illustrates such a flow available here:
The flow described in that example is based on .NET Framework 4.5.2, but a similar flow can be implemented for .NET Core.
Hi @yko ,
I just tried the workaround, and i have the same issue.
it works for .Net but it doesnt works for the .NetCore.
Error detail below:
there is another workaround?
I think the credential part of HttpClientHandler is handled differently in .NET Core compared to .NET Framework. You need to explicitly set it. You can see an example here:
Good! I'm happy to hear that. And thanks again for providing the feedback. Input like this from the community is very valuable for getting the .NET Core version of the SDK to a quality that will allow us to move it out of experimental status.