topic Re: Interpretation of Wildcard In Section Access in App Development

Interpretation of Wildcard In Section Access

mbespartochnyy — Sat, 16 Nov 2024 17:28:58 GMT

Hi there,

I'd like to confirm one thing - how Qlik is reading wildcard symbol in reduction field. I read Managing security with section access document , particularly this sentence:

| "The wildcard, character *, in this row refers only to all values within the section access table."

My question is "Will an admin user (DOMAIN\ADMINUSER in example below) that has an asterisk in the REDUCTION field be able to see all records in the dataModelTable below?"

Here's an example that I'm thinking of:

sectionAccessTable:

ACCESS	USERID	REDUCTION
ADMIN	INTERNAL\SA_SCHEDULER	*
ADMIN	DOMAIN\ADMINUSER	*
USER	DOMAIN\USER1	VALUE1
USER	DOMAIN\USER2	VALUE2
USER	DOMAIN\USER3	VALUE3

dataModelTable:

REDUCTION	Some Other Field
VALUE1	Some Other Value
VALUE2	Some Other Value
VALUE3	Some Other Value
VALUE4	Some Other Value
VALUE5	Some Other Value

In this example, I believe DOMAIN\ADMINUSER account will not be able to see records for VALUE4 and VALUE5 values in REDUCTION field. Is that true?

Thanks,

Mikhail B.

Re: Interpretation of Wildcard In Section Access

joaopaulo_delco — Tue, 16 Feb 2021 18:43:38 GMT

Hi @mbespartochnyy !

In my apps all the user with Access = "ADMIN" have access to all the applications. Even that have with something different that "*". I think you change the value of field "ACCESS" to "USER" to ADMINUSER will solve the problem.

Re: Interpretation of Wildcard In Section Access

mbespartochnyy — Tue, 16 Feb 2021 19:28:03 GMT

Thanks for the reply! I don't really face any problems with section access. I'm trying to understand how it is designed to work, at least from a perspective of wildcard symbol in a reduction field.

What I'm trying to understand is whether an asterisk, when used in a reduction field, referring to all of the values listed in a field in a data model or just the values that have been loaded in a reduction field in section access table.

Re: Interpretation of Wildcard In Section Access

QFabian — Tue, 16 Feb 2021 20:53:50 GMT

Hi @mbespartochnyy for your ADMINUSER, you can left blank for ther REDUCTION field.

for clarity purposes, In a INLINE table should be :

sectionAccessTable:

Load

ACCESS, USERID, REDUCTION
ADMIN, INTERNAL\SA_SCHEDULER,
ADMIN, DOMAIN\ADMINUSER,
USER, DOMAIN\USER1, VALUE1
USER, DOMAIN\USER2, VALUE2
USER, DOMAIN\USER3, VALUE3

Re: Interpretation of Wildcard In Section Access

mbespartochnyy — Tue, 16 Feb 2021 20:57:58 GMT

Thanks, @QFabian! Could you elaborate on that please?

My thought is that if I leave REDUCTION field blank, admin and service account won't have access to any records. Is that not the case?

Re: Interpretation of Wildcard In Section Access

QFabian — Tue, 16 Feb 2021 21:02:22 GMT

sure, if you left it blank, its going to work, remember that you can create a little app with a few data and publish it, just for testing the user on the published app, not dev.

Re: Interpretation of Wildcard In Section Access

mbespartochnyy — Tue, 23 Feb 2021 16:13:47 GMT

I reread the Managing security with section access document and tried out creating a sample app to try things out. It looks like the answer to my question is:

"That is true. That user will only be able to see records for VALUE1, VALUE2, and VALUE3."

That is the case because asterisk is interpreted as all values listed in sectionAccessTable table and it's interpreted that way because we want to be able to control record level access for users with ADMIN value in ACCESS field.

Moreover, there are actually two wildcard characters:

One is an asterisk
And the other is null

Null wildcard value for ADMINUSER account will give access to all possible records in the data model including VALUE4 and VALUE5. That works because a null wildcard value seems to have been designed to eliminate the need to list out every possible value available in the data model for users who have ADMIN value listed in ACCESS field. In other words, this setup:

sectionAccessTable: Load * Inline [ ACCESS, USERID, REDUCTION ADMIN, INTERNAL\SA_SCHEDULER, * ADMIN, DOMAIN\ADMINUSER, * USER, DOMAIN\USER1, VALUE1 USER, DOMAIN\USER2, VALUE2 USER, DOMAIN\USER3, VALUE3 ];

Means that ADMINUSER user has access only to VALUE1, VALUE2, and VALUE3 values.

While this setup:

sectionAccessTable: Load * Inline [ ACCESS, USERID, REDUCTION ADMIN, INTERNAL\SA_SCHEDULER, ADMIN, DOMAIN\ADMINUSER, USER, DOMAIN\USER1, VALUE1 USER, DOMAIN\USER2, VALUE2 USER, DOMAIN\USER3, VALUE3 ];

Means that ADMINUSER user has access to all possible values, including VALUE4 and VALUE5.

Furthermore, if setup is changed to be like this:

sectionAccessTable: Load * Inline [ ACCESS, USERID, REDUCTION ADMIN, INTERNAL\SA_SCHEDULER, ADMIN, DOMAIN\ADMINUSER, USER, DOMAIN\USER1, USER, DOMAIN\USER2, VALUE2 USER, DOMAIN\USER3, VALUE3 ];

It will not work because null value can only be used for users with ADMIN value in ACCESS field. Since USER1 has a USER value in ACCESS field, that user will not have access to any records with this setup. In fact, they will not even be able to open the app. When they'll attempt to open the app, they will get Access Denied message. The app, however, will reload successfully because INTERNAL\SA_SCHEDULER account that's doing the reloading does have access to the app and all records within it.

Moreover, if setup is changed to be this:

sectionAccessTable: Load * Inline [ ACCESS, USERID, REDUCTION ADMIN, INTERNAL\SA_SCHEDULER, ADMIN, DOMAIN\ADMINUSER, USER, DOMAIN\USER1, * USER, DOMAIN\USER2, VALUE2 USER, DOMAIN\USER3, VALUE3 ];

ADMINUSER user will have access to all possible values, including VALUE4 and VALUE5. While USER1 will only have access to VALUE2 and VALUE3.

Lastly, if setup is set to be this:

sectionAccessTable: Load * Inline [ ACCESS, USERID, REDUCTION ADMIN, INTERNAL\SA_SCHEDULER, * ADMIN, DOMAIN\ADMINUSER, * USER, DOMAIN\USER1, * USER, DOMAIN\USER2, VALUE2 USER, DOMAIN\USER3, VALUE3 ];

Both ADMINUSER user and USER1 user will have access only to VALUE2 and VALUE3 values.

That seems to be how Qlik Sense is interpreting asterisk and null wildcard values. Please let me know if I missed or misunderstood anything.

Thanks,

Mikhail B.