Qlik Community

QlikView Documents

Documents for QlikView related information.

Announcements

Breathe easy -- you now have more time to plan your next steps with Qlik!
QlikView 11.2 Extended Support is now valid through December 31, 2020. Click here for more information.

Section Access: Desktop vs Server

Employee
Employee

Section Access: Desktop vs Server

Section Access logic works the same way on QlikView Desktop and QlikView Server side. The QlikView application distribution can however trick you , if you are not aware if how it reduces the document. A section access restricted user can appear to get access to more data than expected or get access denied!

In this example the QlikView Server service account and the application developer are expected to get all values in field F1. The application end-user on the other hand has limited access to the field F1.

2015-05-24 11_36_18-Edit Script [C__Users_tko_Documents_Community Content & Material_Content - Secti.png

The application and Section Access works as expected in QlikView desktop client. Developer gets access to all values in F1 and the user gets limited access in the document. The basic 'deployment' flow in desktop will be as below;

  1. Application is reloaded by Developer
  2. Application is saved to file by Developer
  3. Application is opened by User
  4. Application get reduced based on User's reduction value A
  5. Application shows limited values in F1 to User as expected

On server side the work-flow will be a bit different, potentially leading to unexpected results for the User.


  1. Application is opened by the Service user
  2. Application is reloaded by the Service user
  3. Data in the QVW file is reduced based the Service user reduction value
  4. Application is saved to QVW file by the Service user
  5. QVW is distributed


The distributed QVW file now has reduction values that matches the Service user. In this case it means that REDUCTION field only has ALL as possible value. The User's reduction value A does not exist, and this can lead to two different outcomes when the User opens the application through a web client.

If ---‌ is enabled, the User gets access denied since there is no possible data for the User.

If ---‌ is disabled, the User gets access to all data in the QVW file since the search for reduction value A does not limit the data.

Attachments
Comments
danieloberbilli
Valued Contributor II

Thank you Toni. If both outcomes are not intended/expected - what would we the best solution for the server side regarding your example?

Employee
Employee

Basically the Service User needs to have access to all reduction values, so that it covers all the users needs. By using wildcard star the reduction is equal to all listed values in the section access table.

Solution1.png

Employee
Employee

Possible usernames are the USERID values listed in the image above. Password is not required, so just leave it blank.

b_garside
Valued Contributor

My mistake I left out the Domain prefix. Thanks.

Luminary
Luminary

Hi,

Should that not be NTNAME instead of USERID if you are using DOMAINS?

As a general rule:

USERID = fixed list of users allowed access

NTNAME = look it up in the Network Directory (LDAP, ActiveDirectory, Local users, ODBC)

Tip:

Concatenate it with the QV Service Userid , so that you are not locked out later.

You can always salvage your document by reloading with qv /r /nosecurity /nodata.

Hidden script however is not recoverable.

Kind Regards,

Dion Verbeke

Lead Consultant

Deloitte Belgium

b_garside
Valued Contributor

Great point Dion. I have included both for that very reason to serve as a backdoor account in case I get locked out or need to troubleshoot.

stabben23
Honored Contributor

Hi Toni,

I have exact this problem, but can solve it by adding * to my service account.

I have Strict exclusion disabled. In my application there is 3 different field that could be used in combination, therefore I have to use Generic keys to solve this section access. I have read Henrik Cronström "blogg" about this and build the application like that. And as you mention all works in desktop but not in AccessPoint after distribute by publisher. I also exclude the serviceaccount when I load the section access script oterwise every user will have service account rights, but in this case it gives me nothing in the application because * is not a valid value, is there a bug, I use 11.20 SR 10

Employee
Employee

Hi Staffan, sorry I missed your comment. Have you sorted this out?

Not applicable

Thank you Toni for this article. I had the exact problem and couldn't solve it for the past two weeks. You saved my day! Thank you very much!

Not applicable

Hi,

I have a Section Access Table that looks like this,

   

ACCESS NTNAME PROFIT_CENTER_SA
ADMIN CDADFED1ALL
USER FADBKKLD012 US00001081
USER DAFDSADSFADF003<ANY>
ADMINSERVERNAME*

My goal is to when I run Section Access on the Qlikview Server, give unrestricted access to the server and the profit center without having to create dummy rows in my section access table. Is this possible?

Version history
Revision #:
1 of 1
Last update:
‎05-23-2015 10:00 PM
Updated by: