SA and a BINARY

[datanibbler]

Hi,

I have a question rgd. the combination of a BINARY LOAD, which we have in every app visible to the
"general public" and a SECTION_ACCESS - which comes down to a matter of the order of execution: Is the SA,
as I believe, computed on the server from the Header BEFORE actually doing anything in the qvw? In that case the BINARY
would not be executed on the machine of somebody who is not granted access to the app. Then it could be the very first Statement in the script, as it has to be, and the code to load the SA anew could come afterwards.

Right?
Thanks a lot!
Best regards,

DataNibbler

[tresesco]

AFAIK, binary load gets executed first. And that is why you should always check 'Prohibit Binary Load' (Document Settings->Opening tab) on all the applications that has SA. Because your qvw with SA being binary loaded can always be overridden by a new qvw with another  SA.

[prieper]

Typically these applications should only reside on a server. The server-user needs not to be restricted and needs to be declared as ADMIN.

Therefore the sequence does not matter (actually BINARY must be the first statement), as these files should not be available to the public.

A user, who is not authorized, will not be able to open the application, where there is SA.

A user, who is not authorized as ADMIN will not be able to refresh the application.

Restriction to the baseapplications will need to be handled / governed by Windows.

[datanibbler]

Hi,

the apps do reside on a Server and typically they are reloaded on the Server (by a dedicated user) once a day.

But my question was a Little bit different, owing to the fact that EVERYONE in this Company has a Named_User_CAL, so everyone can basically open any app (which is why we Need the SAs in the first place) and everyone can also reload an app (which no one usually does, but who knows ...)

<=> ah, Forget it, I just noticed my mistake: In principle, everyone can also reload any app and thus execute the BINARY if there is one, but if that Person is not in the SA, he/she won't be allowed to open the app, so he/she won't be allowed to reload it, so there's no issue actually ...

[Peter_Cammaert]

Indeed, there shouldn't be an issue. Even if your users have a Named CAL, you can still restrict or completely deny access to your document. Just don't make them ADMIN.

As a side note, it's a pity that Qlik never created a fine-grained license lease-switch. At the moment it's still a global switch, but if we would be able to tell the QMC that this user should be able to lease his/her license, and that one shouldn't, things would become much simpler and IMHO security would become stricter.

[prieper]

Hi Tresesco,

as far as I know, the BINARY-load restricts the amount of data to your profile, i.e. when you are not allowed to see the entire dataset, you will load in the binary only those data, which you are allowed to.

Not quite sure, whether you are still able to overwrite the SA in such document (it was possible in earlier versions), but then you need to know the exact structure of the SA-file.

edit: incorrect statement

[Peter_Cammaert]

If I remember correctly, recent discussions on that lmatter came to the conclusion that the SA from the original QVW would come over with the BINARY LOAD and couldn't be modified in any way. The first SA is final.

I'll check if I can find one of those dicussions...

[Peter_Cammaert]

Actually, the recent one wasn't conclusive.

But this one may shed some light: binary and section acess?

[tresesco]

Hi Peter,

I might not be able to SEE the entire data, but it is STILL THERE at the back-end, I believe. This nature makes sense to me, because you are not really loading (read reload) the data to restrict, unlike publisher.

And yes, I carried out a small testing (not rigorous though) in recent version QV 12.1, and it seems that I was not wrong; qv SA gets overridden still today as I explained above.

[Peter_Cammaert]

So you are saying that the original SA wont restrict what the BINARY load imports into the current document (or there wouldn't be a complete data model with all records in the background), and since the new SA is never made active during the load that creates the SA table, a new SA will become active as soon as the new document is saved and reopened. Thereby eliminating the original SA from the first document, correct?