Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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
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.....
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.
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
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.
Ah thanks Jakub. Ill give that a try and feedback.
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.....
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...
This worked for us too. Very odd behaviour. We are using QlikView Server version 11.20.12904.0
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!!!!