Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
I have a situation where a Linux web server is validating the user and checking the credentials. From there, the Linux Web server gives the user a link to a QlikView document.
When the user clicks on it, the Linux web server needs to gtet a ticket. All good so far, I understand how to get the ticket code and such.
But, I have some questions. One is how can the Linux web server be part of the QlikView Server Administrators Group. I'm assuming they can't. In that case, what options are available for the Linux machine to get a secure ticket (so that I don't have to open the QVS up to give tickets out to anyone). In older versions of QVS (8.2, 8.5?) there was an option to allow for a specific IP address to be configured into the QVS to allow that one IP address machine to request a ticket. Is this still the case with QV10 and QV11 &/or is there another method? If the IP address is the method, do you know where to specify the IP address?Thanks
I have never tried to get a ticket from a linux machine, but since there isn't any other answer given...I will give it a try.
Can you provide some more information about your network architecture?
Do you use a Linux web server and a Windows QlikView server?
How do you run the QlikView web server, as a windows service or using IIS?
For ticketing you can create a local windows user account on the QlikView Server.
Make it a member of the QlikView Administrators group.
Pass the credentials of this user when requesting a ticket from the linux server.
As far as I know there is no option in QVS to allow one IP address to request a ticket.
You can use IP restrictions if QlikView Webserver is running in IIS.
Hi All,
I have done it before... I don't have a code with me but you are getting the concept wrong.
There is a two phase process. First you have to identify yourself in Qlikview saying that you are the userX and that user is part of the Qlikview Admin Group. After that you ask for a ticket for the userY.
Then what is going on is that with the ticket process Qlikview Server will only see if the request code have the NTNAME for a user that is in the Qlikview Admin group. If that is correct we will give a ticket for the NTNAME requested. There is not checking directly about the "linux user" but the user that is in the request code, that is way using this process is the developer that needs to have the responsability of managing the Qlikview Access. To avoid "tricks" with this process only one session is allowed for each user (offcourse) .
Tell me if this help you or you would like further information.
Best regards,
Vasco
As well as ticketing you could use HTTP header authentication instead. The Linux web server would act as a reverse proxy server and add the authenticated user name into the HTTP header of the requests made to the QV Server
All,
Not sure if you've solved the issue yet, but I recently encountered a similar problem at a client and blogged about the solution: http://www.qlikvlad.com/?p=157
Hope this helps.
Vlad
Vlad, I tried to comment on your blog but it was rejected for banned words so I'll comment here. The code you posed has serious security problems. You sent the qlikview administrator username and password to the end user with the xmlHttp.open line. Just view source in the client browser and you'll see the username and password.
As for the OP, you can certainly get a ticket from a linux machine. As others have said you will need to get a ticket by logging in as a QlikView Administrator user. The difficulty is that you will need to authenticate with NTLM (and probably NTLMv2). We use jcifs with java; there may be an apache module that can do the same. The other option is to qlikview server with IIS and change the authetication on GetTicket.aspx to basic but you should only do this if you have SSL enabled.
Yeah I realized that problem today. I'm leaning toward obfuscating the code with a free obfuscator and leaving it the same. Going to modify the blog soon.
Regards,
Vlad
FYI, updated procedure has been posted that fixes the security problems.
Vlad
Just to let you know, my blog has moved so the post above can now be found here: http://www.infinityinsight.com/blog/?p=157
Regards,
Vlad
Thanks Vasco for putting it in perspective.
I haven't tried it yet, but this looks like the right 'mindset' for solving it. We didn't go ahead with this implementation previously, but I'll keep this in mind on my next and post how it works.