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.
- When a session times out, the session data is removed from the QlikView server.
- When the same client in step one tries to reload, hit back, or click on an object or report the browser (which has the credentials information cached) re-submits the data and QlikView allows the re-authentication to take place successfully. This effectively loads whatever the client was trying to load without ever taking you to a Login Page. It behaves as though the session never ended.
- If the session is removed manually by the client the same things that happen in step 2 occur.
- If a client closes the browser and the session times out or is removed the login page appears when the client next tries to connect to QlikView. Closing the browser clears the cached credentials which is standard web browser behavior.
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.
