Unexpected behavior (bug?) with * (star) in Section Access

[nstefaniuk]

Hello.

I have an unexpected behavior, maybe a bug, using * in section access in a very basic test.

Here is an application with 2 embedded users:

USER1 should see A,B

USER2 should see A,B,C but is blocked because "*" is not taken in account.

LOAD * INLINE

[ACCESS,USERID,PASSWORD,DIMENSION1

DUMMY,DUMMY,DUMMY,C

ADMIN,USER1,USER1,A

ADMIN,USER1,USER1,B

USER,USER2,USER2,*

];

"*" is taken in account if :

- source table used for SA has not exactly the same fields than SA table

or

- if source table is dropped after the SA

Of course I may have missed something obvious (often the case with a "bug" in Qlikview) but I am confused with this behavior.

It could be because there are 2 tables filtered by the security field, but this issue should occur with explicit values too. It seems that when Qlikview tries to open application it checks authorized values then encounter * and is blocked because 2 tables are associated on this field.

What is your opinion ?

Tested in 11.2 and 12.0

Thanks a lot

[andydietler]

Does the dummy line need a real ACCESS value? I usually put "USER, DUMMY, DUMMY, C" when I do the same.

[nstefaniuk]

So everybody can open your application with account DUMMY/DUMMY and have access to all data ? Using a "DUMMY" Access value is done on purpose to prevent opening the application with this account.

[Peter_Cammaert]

One of the golden rules of Section Access is that you can create circular references between Section Access and Section Application but only if multiple links from SA exist to individual fields in different tables in Section Application. Not to multiple fields in the same Section Application table.

And no, this isn't documented anywhere except in the Community and in some extremely old security training material.

[nstefaniuk]

I agree but I use only 1 field in my SA table. I am in the case of 2 tables in application filtered by 1 field from SA table.

[nstefaniuk]

In my opinion, after some tests it's even worse than before. In this last application I can mess up USER2's login by removing a row in a not associated table.

I think that when a SA table is created something tricky is done in memory and in this exact case it goes wrong.

Can someone try this application in his environment and report results please ?

Thanks a lot

[Peter_Cammaert · Accepted solution]

Not really.

Your question was (amongst others): "...it only works if I drop the source table or if the source table has not exactly the same fields than SA table...". The source table currently has the exact same layout as your Section Access table.

[nstefaniuk]

You are totally right, I have been misled because in some tests I could change the behavior with a rename in the security field, but ACCESS, USERID and PASSWORD exist in SA table too and so it's probably the reason.

So no bug, old known behavior where you mustn't have more than 1 field associated with your SA table.

I was sure it was something obvious but couldn't spot it. I am relieved, thanks Peter. Again a case where the bug was behind keyboard and chair

[Peter_Cammaert]

Glad you were able to figure it out.

Good luck !

[andydietler]

DUMMY wouldn't have any access to the app unless you gave it to them in the QMC.