Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Section Access Problem - AccessPoint / NTNAME

Server Version 11.20.12451.0

Ive encountering a strange problem with section access when trying to open a document on Accesspoint. I have created other section access documents and they are opening OK. I have created a small test case to verify my problem and it is using another solution to the contradictory situation as ibove;

NTNAME     COMPANY     PRODUCT

JSMITH          SBUK               *

JSMITH            *                   RESINS

In my example the Section Access bit of code in the script is as follows;

Load

* INLINE [
ACCESS,NTNAME,%AuthID
ADMIN,S_QLIKVIEW,*|*|*
ADMIN,FRED.BLOGGS,A|*|*
]
;

When I use non the nonNT/AD : USERID, it works fine. When I apply NTNAME and run on server, then open the the document from the server (ie logged onto the general network as FRED.BLOGGS) the document opens in my desktop version with the data restricted as expected. (Note I have strict exclusion applied)

PROD CUST SITE Value AuthID AB001XLTD231.23A|B001|XLTD

If I then try and open the same document via access points I get the message "Failed to Open the Document. You do not have Access to the document"

If I switch off strict exclusion, I can open the document in Accesspoint but I get to see all records. If I set the section access to the equivalent of all in my composite AuthID key (*|*|*) the document opens in Accesspoint and I see all records. Has anyone encountered a similar issue?

Original Post advising approach

http://community.qlik.com/blogs/qlikviewdesignblog/2012/10/02/complex-authorization

1 Solution

Accepted Solutions
Not applicable
Author

Very strange this. We changed the Section Auth Table to have non valid data in another dummy user line and it has started working. Not sure why.

e.g.

ACCESS,NTNAME,PROD,CUST,SITE

ADMIN,SVCACC,ALL,ALL,ALL

ADMIN,USERTOWORK,PROD1,ALL,ALL

DUMMY,DUMMY,NONSENSE,ALL,ALL

very strange.....

View solution in original post

8 Replies
Peter_Cammaert
Partner - Champion III
Partner - Champion III

Your link field %AuthID makes the document reduce to nothing. That explains why in the AccessPoint when strinct exclusion is enabled, you don't get in, and when strict exclusion is disabled, you see everything.

The Desktop works differently only because of the ADMIN role. As soon as the Desktop faces an authenticated user with role ADMIN, it will let you in en display all data. Always. ADMIN users are mostly the developers themselves.

BTW QlikView has no real wildcard concept in Section Access, especially not something like *|*|* meaning all combinations of three key elements. The single * (asterisk) can be used, but that only expands to all values in the same field (inside the section access table, that is). This leads to both link values *|*|* and A|*|* to be allowed as-is, but they probably don't exist in your Section Application field with the same name.

Not applicable
Author

Firstly, Thank you for your very prompt response Peter. Much appreciated. I was misleading with my wildcard. I tried it first with A|ALL|ALL  (or could have been A|NA|NA)  with the same effect. I have other section access docs working fine using wildcards and dummy lines in section access to ensure all occurances of the filter fields are picked up. (ie wildcard only picks up other section access content). It just seems to be this particular approach outlines in the blog link above which is causing this problem. Its a strange one. I have since tested on a diffierent Server which is Server Licence only not Server Publisher per the original and have the same issue.

A|ALL|ALL failed but ALL|ALL|ALL (or *|*|*) let me in through Accesspoint in my example

kuba_michalik
Partner - Specialist
Partner - Specialist

If S_QLIKVIEW is the service account, better make it unassociated with any %AuthIDs, even *|*|* :

* INLINE [
ACCESS,NTNAME,%AuthID
ADMIN,S_QLIKVIEW
ADMIN,FRED.BLOGGS,A|*|*
]
;


Otherwise you risk triggering data reduction during distribution to Access Point (and even if all actual data remains, some "connecting paths" in your security-related tables might get reduced, cutting out users which have any %AuthIDs other than the service account).

As the service account has ADMIN access, it will be granted access anyway, even with Strict Exclusion, and will be able to perform distribution and reloads.

Not applicable
Author

Ah thanks Jakub. Ill give that a try and feedback.

Not applicable
Author

Very strange this. We changed the Section Auth Table to have non valid data in another dummy user line and it has started working. Not sure why.

e.g.

ACCESS,NTNAME,PROD,CUST,SITE

ADMIN,SVCACC,ALL,ALL,ALL

ADMIN,USERTOWORK,PROD1,ALL,ALL

DUMMY,DUMMY,NONSENSE,ALL,ALL

very strange.....

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Ahum, are you now using a 3-way relationship PORD-CUST-SITE between the section access table and some other table in section application (causing QlikView to create a synthetic key that is cut to pieces when section access goes into hiding) or a 3-way connection to three different tables in section application (causing QlikView to create Circular References that are cut short when section access goes into hiding but make your model behave erratically)? Or is it just an example to show us the value combinations while not really corresponding with your actual situation?

Very strange indeed...

michaelfentondata
Partner - Contributor III
Partner - Contributor III

This worked for us too. Very odd behaviour.  We are using QlikView Server version 11.20.12904.0

justaqlikker
Contributor III
Contributor III

Kuba_michalik, you completely solved my problem!  

 

I had the exact same problem and symptoms as the original poster of this thread; however, I did not like his solution of inserting a "dummy" record as I wanted to understand the source of this issue.  For me the issue popped up when I modified an existing Section Access implementation and I could not understand why it broke.

 

Removing all dimensions (%AuthID) from the service account running QlikView QlikView Distribution Services was the only change I made.  I set it just like you showed: Admin, ServiceName.  And this fixed everything.  Thank you!!!!