topic Re: Section access challenges in QlikView

Section access challenges

Thu, 26 Dec 2013 19:49:44 GMT

Hi,

First, let me say that I don't have a lot of QlikView experiences. So the challenges and my questions below may be because of my lack of understanding, or something that can be (or have been) solved with some simple solutions. I tried to do my homework upfront, and searched in this community as well as on the net, but didn't find anything that solved my issues.

What I need to accomplish:

I have a .net app that loads QlikView OCX, and allows user to create QVW files which they can open later.

I need to find a solution where if a QVW is created from my app, it can not be opened/used by other apps that may also contain QlikView OCX, or even the stand-alone QlikView installation itself.

My first thought was to create a section access that only my app knows, so if user tries to open that QVW file in other app, QlikView will challenge the user with username/password, and stop the access.

Issues:

1. We want to create a unique username/password for each of our users, and stick them in the section access in the hidden script. However, there's no automation API that allows us to create a hidden script section, so we can't dynamically generate a unique section access code at run-time.

2. The next best thing then is to have section access be based on some external data source (like a text file, which we can generate at run-time). However, the load statement does not seem to be executed every time the QVW is opened. Attached is a simple QVW that illustrate this. The credential in the section access from the previous script reload was "dba/sql" (no quotes), but since the last reload, I have changed the section access code to have the new credential to be "dba1/sql1" (no quotes). However, when QlikView opens this QVW, dba/sql is still valid, and not dba1/sql1.

3. It also seems that once a QVW is opened in an instance of QlikView, the subsequent opening of the same QVW does not trigger section access check, even if there have been other QVWs opened in between. Only when QlikView shuts down in between two openings of the same QVW will cause QlikView to prompt for user credential.

Any thought or suggestion would be very much appreciated.

Happy holidays.

Wei

Re: Section access challenges

Gysbert_Wassenaar — Fri, 27 Dec 2013 07:31:59 GMT

1. You could put code in the hidden script to generate user names and passwords. But it's easier to use an external data source.

2. The Section Access table is loaded when the document is reloaded. If you use an external data source for section access and you edit that external data source then you need to reload your qlikview document to apply the changes to your section access table.

3. That's a user preference. On the General tab uncheck the option Remember Login Credentials Until Qlikview Exits.

Re: Section access challenges

Peter_Cammaert — Fri, 27 Dec 2013 10:14:28 GMT

Upon creating a new user-specific QVW, your .net application can set the value of variables before performing a reload and storing the QVW file. Use those variables in your Section Access table to define a single user, like in:

Section Access;

SA_Data:

LOAD * INLINE [

ACCESS, USERID, PASSWORD

USER, $(vUserName), $(vPassword)

];

Section Application;

In this case, set variables vUserName and vPassword to specific values before storing the document. The code can be builtin upfront in the hidden script in your source document.

As Gysbert says, you'll always need to perform a reload before any change to SA security becomes active.

Best,

Peter

Re: Section access challenges

Mon, 30 Dec 2013 15:54:33 GMT

Thank you Peter and Gysbert for your insightful responses.

Re: Section access challenges

dgreenberg — Mon, 14 Sep 2015 21:23:52 GMT

Thanks Peter, I kept thinking it would be literally passing $(vPassword) because it wasn't in gray - doh!

Re: Section access challenges

Peter_Cammaert — Tue, 15 Sep 2015 06:37:12 GMT

That's the magic of Dollar Sign Expansion: DSE happens anyway, whatever you write between the (alledged) start of a statement and the terminating semicolon.

To show you what I mean, the statement above could be written (allow me ) as follows:

SET STATEMENT_LOAD = LOAD;

SET LOAD_SOURCE_INLINE = INLINE;

SET LEFT_BRACKET = [;

SET RIGHT_BRACKET = ];

SA_Data:

$(STATEMENT_LOAD) * $(LOAD_SOURCE_INLINE) $(LEFT_BRACKET)

ACCESS, USERID, PASSWORD

USER, $(vUserName), $(vPassword)

$(RIGHT_BRACKET);

At first sight, the script engine wouldn't know what to make of this piece of junk. But after DSE...