Qlik Community

QlikView Security & Governance

Discussion Board for collaboration on QlikView Security and Governance.

Announcements
QlikView Fans! We’d love to hear from you.
Share your QlikView feedback with the product team… Click here to participate in our 5-minute survey.
Rules, plus terms and conditions, can be found here.
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?

Tags (2)
8 Replies
Not applicable

Re: Strange Section Access behavior

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?

Re: Strange Section Access behavior

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

Re: Strange Section Access behavior

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?

Re: Strange Section Access behavior

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?

Re: Strange Section Access behavior

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

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

Not applicable

Re: Strange Section Access behavior

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?

Re: Strange Section Access behavior

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

Re: Strange Section Access behavior

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.

Community Browser