I've just started playing with this under QV9 SR1. Right now I'm using the QV Web Server, but will go to IIS on a separate box shortly.
I set up a little VBScript file to test this. Here it is:
InputBox "ticket","ticket",GetATicket("myuserid")
Function GetATicket(userID)
Dim client, cmd, ticketXML, objXMLDoc
Const QVSERVER = "myqlikviewserver.mydomain.com"
Set client= CreateObject("QvsRemote.Client")
client.AdminConnect QVSERVER
cmd="<Global method='GetTicket'><UserId>" & userID & "</UserId></Global>"
ticketXML = client.Execute(cmd)
Set objXMLDoc = CreateObject("Microsoft.XMLDOM")
objXMLDoc.async = False
objXMLDoc.loadXML(ticketXML)
GetATicket = objXMLDoc.documentElement.selectSingleNode("//_retval_").text
End Function
(Note that this is just for testing. A real routine would have much beefier error checking and graceful recovery.)
This seems to work when I run it on the QV9 Server. It relies on a DLL to be installed that handles the call to create the QvsRemote.Client call. The DLL is installed as part of the QVS install. I haven't tried it yet, but I believe it's also installed as part of the web connector stuff if you have IIS on a separate box from QVS.
So if you run this little app (setting myuserid to your user id), it will create a big ticket string, such as 841F141FBF15EE2EABF3CD1533A6D2C2E5CF39AC.
For this to be of any use to you, your server must be using DMS authentication on the QV Server.
If you know the URL to your QV document, for example:
http://mycompany.mydomain.com/QvAJAXZfc/AccessPoint.aspx?open=&id=QVS@mydomain%7CRefreshTest.qvw&cli...
You can can add "&userid=841F141FBF15EE2EABF3CD1533A6D2C2E5CF39AC" to the end, for example:
http://mycompany.mydomain.com/QvAJAXZfc/AccessPoint.aspx?open=&id=QVS@mydomain%7CRefreshTest.qvw&cli...
So what does this get you? It's assumed that you have already authenticated the user. The ticket assures you that this user is authorized to use the document that's being requested.
For example, where I work, we have our own authentication system. When users ask for a QV document, we intercept those requests and instead, send them off to our own authentication system. They enter their user ids and passwords to prove *who* they are, and are then sent back to our web server. So far, we know who they are, but that doesn't mean they are allowed to see our QV documents. At this point, we request the ticket and redirect them to the actual document with the ticket appended to the end of the URL.
When the ticket is generated, it keeps a record of it on the qlickview server for some short period of time. When they request the document with the ticket, QV knows who they are, and checks the document security to make sure they are authorized to actually view it.
I hope that made sense. Best of luck.
