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

Strange Section Access behavior

For some reason, the Section Access Security works fine with a basic user id from C drive.

When the file is moved to  root drive of web server, that same ID will get deined.

Seems to me there is something Qlikview is looking for to keep that user ID with combination of drive location (or web root dir) to deined.

Is this tracked in registry or file somewhere that can be cleared?

I have tried creating a new app by beginning with the backup copy with no section security.

Tested it in C: and works.

Tested in root drive fail.

Also, for unknown reason, opening of the app via web using that Section Access ID will fail.  However, not all other "basic" users will fail, liked ADMIN and some other USER .

Why?

8 Replies
Not applicable
Author

btw, i have notice if I comment out the LoAD block after the 

Section Application:

/*

LOAD *[

...

*/

then the basic user login will work fine.  That is the login window will comes up.

Once uncomment the LOAD block under section application, reload, save, that very same basic user login will get a deined when login.

why?

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Well the intricacies of Section Access are not very easy to explain. At the risk of not making myself particularly clear, here goes:

  • If you use Data reduction based on section access ,and there is a connection between section access and section application, then the resulting data set after data reduction will determine whether a user is granted access. No data remains after data reduciton = no access.
  • If you use Data reduction based on section access, but there is no link between section access and section application (because of being commented out), then the section access table will only be used to look up users with access to the document. Data reduction will not have any effect.


Best,


Peter

Not applicable
Author

That's actually very helpful.

The strange thing is when I'm using an ID that hasn't been used by my app before, opening from web root dir will also denied it.

Is there a place to reset the ID?

Peter_Cammaert
Partner - Champion III
Partner - Champion III

The data in your section access table is only refreshed during a reload. So how would Section Access know about a user that has "not been used by my app before"?

BTW Is your Section Access using NTNAME or USERID to identify users?

Peter_Cammaert
Partner - Champion III
Partner - Champion III

"That's actually very helpful". Ok...

Helpfuls can be marked as such using the corresponding item in the Actions menu. Thanks.

Not applicable
Author

Section Access is using USERID

"So how would Section Access know about a user that has "not been used by my app before"?"

Yup, strange, indeed.

It seems as if the USERID used in this brand new app is generic enough that it is known by the "Reducer's" Section Access to denied.

How to clear it?

Peter_Cammaert
Partner - Champion III
Partner - Champion III

From your second post I get that the login window doesn't appear when you try to open the document in the AccessPoint? It only appears when you comment out the Load of the link values in Section Application?

Not applicable
Author

The login window comes up and deny the user, at access pt when the LOAD statement is not comment out.

It prompts user for password when commmented out the LOAD block.

And there is data for the USERID to browse.