Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
We have struggled with Qlikview security and session timeouts for our off-site employees for the past couple of years. Currently, we use a VPN connection to secure access to the QV server and report data for our off-site employees, but bandwidth limitations make it difficult to access large amounts of report data for some of them.
I think we can agree that there is a problem with the way basic security has been implemented with the Qlikview web solution because session timeouts do not ask a user to re-authenticate. We recently worked with a web developer to review the code and make a recommendation for securing the site properly.
Here’s how QV is working currently.
In previous dialog with QlikView, they’ve said this can’t be fixed because the authentication information is stored in the browser and there is no way the server can clear that information. This is inaccurate because when a session is removed from the server, the requested object or page should not allow the credentials to be submitted to the server when the session value is null or does not match a current session on the server. This is done with a few simple If statements on the sever side code. In the next paragraph, we’ve provided an example of the code required to fix this problem. This code is for the front end (browser) and an example of what can be implemented server side to secure access. We don’t have access to server side to make this change.
if (($(c).find("value[name='Redirect']").attr("mode") == "enabled") && ($(c).find("value[name='Redirect']").attr("value") == "/qlikview/login.htm")) {
window.location.href = '/qlikview/login2.htm';
return;
This issue has been well documented in the Qlikview forums, yet they continue to ignore the problem and frustrate their customers who are trying to secure sensitive corporate data. We planned to submit this suggestion as an enhancement request on the QV site but Qlik.com does not have any area on their site to post suggestions or enhancement requests. We continue to bring this issue up, but it is inexcusable that QV has ignored a security vulnerability of this magnitude that can be easily fixed with a few lines of server side code.
Hi Larry! Which version of QlikView server do you have installed?
I just want to know what QV have to say about this...
We are currently using 11.20 SR4. QlikView had us try SR5 and SR6 but we didn't see any security improvements in either of those that corrected the issues we stated so we stayed on SR4. I can't speak to any of the more current SR's.
We are continually being told this was going to be fixed but they are approaching this as if it really isn't a problem. They keep telling us they are working to get this resolved, and it hasn't been resolved for over three years!
Can I also ask which settings you have configured in the QMC under "QlikView Web Servers->Authentication->Type" and "QlikView Web Servers->Authentication->Login Address" for your setup?
If using the option "Default login page (browser authentication)" under "QlikView Web Servers->Authentication->Login Address" have you considered using web-form authentication instead?
Authentication = Always
Type = NTLM
Login Address = Default login page
we are currently using the QV web server we have tried to fix this with every possible setting change and by switching to IIS so please don't try to recommend just a setting change.
Just wanted to follow up here as I got a Customer reffering too this Thread.
I tried to check the Details of your issue but could not find any open Case. For me it sound like an issue with the Configuration as ou use the Default login page (browser authentication). This is the default setting as most customer like to use Single Sign On with their Active Directory. If you change to Alternate login page (web form) and the user ran into a timeout a WebPage will come up and you have to sign in again.