Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

OCX::GetServerDocList Authentication/Authorization

I do NOT have a central login, i.e. I do NOT use Active Directory but use Local User name/pswd that is authenticated locally when I login to Windows. I have the same account name on a laptop and on a WIn Server hosting QVServer. I have an app with an embedded OCX.

I use the OCX method GetServerDocList to get a list of documents on the QVServer:

   QlikView.IArrayOfDocListEntry docs = myOCX.GetServerDocList("qvp://<servername>");

The method is defined to only take a server url.

I find that I have to have the same name and password on both the laptop and Win Server I get a list of documents.

But if I have same name but different passwords I do not get a document list back.

I thought that QlikTech left authentication to my Windows login process. And that QlikTech only needed the username to then do authorization because it assumed the username has been authenticated already.

Why is QVServer requiring the same passwords?

What is the OCX adding to the GetServerDocList info passed to QVServer?

1 Reply
Not applicable
Author

I have used NetMon to monitor the traffic between my application (on my laptop) and the Windows Server hosting QVServer and the QMS that responds to the QMSAPI calls.

It appears that as part of the HTTP Post that is done as part of the QMSAPI Call to GetServerDocList on the host, there is first a behind the scenes NTLM challenge/response.

The Login name under which the app is running (in my case the Windows Desktop login, but if the app were a service then it would be the login property associated with the service) is sent to the host, the host sends back a string that needs to be hashed using the password associated with the login, the hashing is done, the response sent to the host, the host sendw the same string off to be hashed using the password ON THE HOST that is associated with the login name that was sent. If both hash values match … the NTLM process generates a SessionID that is returned to the app and the app resends the post using the SessionID and the host that accepts the request and satisfies it.

All this NTML stuff happens "behind the scenes".

The App is not involved in password lookup, hashing etc.