Selectively allow QVW download

One of the client options that are available for accessing applications via the AccessPoint is "Download." Selecting "Download" will allow the user to download a copy of the QVW for offline analysis of the document. Most organizations, however, typically do not want to allow users to work with local copies of the QVW; by forcing users to view their applications in one of the hosted clients, they can ensure that users are always working with the latest version in a secure environment. Nevertheless, sometimes an offline version of the application becomes necessary, such as when a user will be without internet access and needs to use the application. Companies may want to create an exception to allow such users to download applications—the problem is there is no built-in method to enable downloading selectively. This article outlines one procedure for adding this functionality.

Step 1 - Disable Document Download
Since the AccessPoint and QEMC do not have a built-in method for allowing selective downloads, the first step is to disable downloads across the board. You can either do this (a) at a document level, by unchecking "Download" in the Source Documents task or the User Documents published version; or (b) for all documents on the server by unchecking "Allow Document Download" in QEMC >> System >> QlikView Servers >> Documents (this setting overrides individual settings at the document level).

Step 2 - Define QVW MIME Type
The procedure in this article will require creation of a custom link to the QVW application. By default, web servers do not understand how to handle most file extensions; they need to be "taught" by defining a MIME (Multipurpose Internet Mail Extensions) type. For our purposes, we need to create a .QVW MIME type in either QVWS or IIS, depending on which one you are using:
QVWS: Open QEMC >> System >> QlikView Web Servers >> Web. Create a new .QVW MIME Type here and define it as application/octet-stream. Click "Apply."
IIS6: In IIS Manager, right-click on Default Web Site (or whichever site you installed QlikView under) and click Properties. Select the "HTTP Headers" tab, click "MIME Types" and then "New." In the Extension box, type QVW. In the MIME type box, type application/octet-stream. Click "OK."
IIS7: Navigate to Default Web Site (or whichever site you installed QlikView under). In the Features view, double-click MIME Types. In the right Actions pane, select "Add." In the Add MIME Type dialog box, type QVW in the File name extension text box. Type application/octet-stream in the MIME type text box. Click "OK."

Step 3 - Creating/Securing a Downloadable Copy of the Application
In this next step, we need to implement Windows security. We will be creating a link to download the application, but we clearly do not want the download link to point to the version of the application hosted on the AccessPoint—this version gives too many users access. The idea is that we do not want users to simply email the link to each other because not all users should be allowed download rights. The problem with the AccessPoint version is that all users who have web access will, by definition, have NTFS Read permissions on the application (and will be able to download it if they have the URL). Rather, follow the below steps to create a secure copy of the application:
Step 3a: Create a new folder in your AccessPoint folder structure called "Downloads."
Step 3b: In your web server, define a path to this Downloads folder. If you are using IIS, create a new virtual application called "Downloads" and point it to the physical path of Downloads on the server. If you are using QVWS, open QEMC >> System >> QlikView Web Servers >> Web, and define a new "Downloads" Root Folder pointed to the physical path of Downloads on the server.
Step 3c: Define the Downloads folder as a Mount in QVS by going to QEMC >> System >> QlikView Servers >> Folders.
Step 3d: Create a second Publisher distribution task on your Source Documents QVW. Set this task to trigger on completion of the main reload/distribution task on the QVW. The task should distribute to the new Downloads mount, and only to users that have download rights on the application. Since this task is triggered after the document has already been reloaded, a second reload is not necessary, so uncheck "Enable Reload" in the Reload tab of the task. This distribution will automatically set up correct NTFS permissions on the downloadable version of the document; Windows-based web servers, including IIS and QVWS, will respect NTFS permissions and not allow unauthorized users to download the application.

Step 4 - Creating the Download Link
Next, we need to create a link within the main (AccessPoint-hosted) application to download the QVW. Changes should, of course, be done to the Source Documents version since that will overwrite the currently published version on next reload. The link within this application will be hidden to all users who do not have download permissions—for these users, the web application with be their final destination. Users with download privileges, however, will be able to use this link to download a local copy of the application. This link will usually be contained in a text object or a button. For example, if your secured application is called MyApp.qvw and is located in the Downloads virtual folder on a server called qvs01, create a text object or button called "Download Application" and, under Actions >> External >> Open URL, define the URL to be http://qvs01/Downloads/MyApp.qvw.

Step 5 - Identifying Users and Displaying the Link
The next step is selectively hiding this link based on user identity. In order to selectively show some users the link but not others, we need to determine the user's identity and check that against something. There are 2 primary ways to do so: (a) using the OSUSER() function, and (b) using Section Access.
Method A - OSUSER: If you have a relatively small number of users with download rights, the fastest and easiest way to identify these users is with the OSUSER() function, which returns the logged-in Windows identity of the user. Edit the script of your application to add the following small island table:

SET HidePrefix='%';


Right-click on the link created in Step #4, select Properties, and go to the Layout tab. Under Show, select "Conditional" and define the condition to be something like this: upper(osuser())='MYDOMAINUSER1' and fieldindex('%SHOWLINK',1)>0
This will display the link only to USER1. You can add more users to this expression using an OR operator, but if you have more than a handful of users, you may want to consider using Method B instead. Reload, save and close the application.
Method B - Section Access: This method is appropriate if you have a significant amount of users with download rights. Before you make any Section Access modifications, I strongly suggest you backup your application so you do not accidentally get locked out. Create a CSV file with a list of Windows usernames of the users who should be allowed download rights to the application (CSV files work better in Section Access than XLS spreadsheets). Having these users organized within one spreadsheet will also make administration of the list easier in the future. Edit the script of your application to add logic similar to the following:

SET HidePrefix='%';

//Step 1: Define your ADMIN group (QlikView and document administrators)

//Step 2: Read in the CSV file of users with download rights
     'USER' as ACCESS,
     upper(NTNAME) as NTNAME,
(txt, codepage is 1252, embedded labels, delimiter is 't', msq);

//Step 3: Remove download rights from all remaining users

Star is *;
Section Access;




drop table security;

In Settings >> Document Properties >> Opening, check "Initial Reduction Based on Section Access" and uncheck "Strict Exclusion." In the Security tab, check "Admin Override Security"; you can also use this tab to set any other user security preferences you wish. Finally, for added security, you can hide the Section Access script tab by selecting File >> Create Hidden Script.
Right-click on the link created in Step #4, select Properties, and go to the Layout tab. Under Show, select "Conditional" and define the condition to be the following: fieldindex('%DOWNLOADFLAG',1)>0 and fieldindex('%SHOWLINK',1)>0
Reload, save and close the application. Administrators and all users defined in the CSV file will be shown the download link, while other users will not see that link. The QVW has now also been secured with proper NTFS permissions to further ensure that only authorized users will be able to successfully download it.

Step 6 - Publisher Reduction
Finally, we need to disable the download link within the downloadable version of the QVW itself. In Step 5, we created a flag field called %SHOWLINK. In the QEMC, open the Publisher distribution task created in Step 3d. Go to the Reduce tab and press "Open Document." Under Simple Reduce, find the %SHOWLINK field in the left pane, and select '0' in the right pane. Press Apply. Because we are using the %SHOWLINK flag as part of the Show condition in the download link, reducing this flag to only value '0' will ensure that the download link will not be redundantly displayed in the downloadable version of the application. Start the Publisher task chain by starting the first task in the chain (to reload and distribute the main application). This will trigger the downloadable version distribution task as well. When the tasks complete, the process is done: you are left with a main version of the application that will selectively and securely show the download link to authorized users only!

UPDATE: As of QlikView v11, document downloads can be managed per document and per user directly through the QMC.

This entry was posted in Server. Bookmark the permalink.

2 Responses to Selectively allow QVW download

  1. Sandeep says:

    is there a limit on .qvw size that a User can download on to his laptop for offline usage.
    we are hitting “out of memory” issue when a User downloads a 10MB+ file from accesspoint to his desktop.

  2. Vlad Gutkovsky says:


    This sounds to me to be an unrelated issue–the solution described in this blog post has no file size limit.


Leave a Reply

Your email address will not be published. Required fields are marked *

Notify via email when new comments are added

Blog Home