Can I use QlikView Tickets AND Basic Authentication on the same server?

[#1]

Running QlikView 10

2 servers, one running IIS as the website and the other running QVS, both with Windows 2008 EE 64bit

Application using tickets works fine - only authorized users can see and open documents.

Remaining application is not scheduled to be converted to use tickets, will still use basic authentication.

Using IE and Ajax client

Some of the symptoms I am getting on the broken application:

1. I see ALL documents, even ones I am not supposed to.

2. I can not open any documents, I get a Failed to Authenticate popup followed by a No Connection popup.

3. The QVServer log shows this error twice:

     2012-08-28 11:23:58    2012-08-30 15:29:41    4    700    Information    Session stop reason: negotiating failed - no anonymous access allowed

4. The Windows Event Viewer on the QVS shows:

     The description for Event ID 700 from source QlikViewServer cannot be found. Either the component that raises this event is not installed on your local      computer or the installation is corrupted. You can install or repair the component on the local computer.

      If the event originated on another computer, the display information had to be saved with the event.

      The following information was included with the event:

      Session stop reason: negotiating failed - no anonymous access allowed

      The specified resource type cannot be found in the image file

I have tried everything I can think of in obviously every combination except the one that works.

While I am new to QlikView, I do have a fair amount of IIS/website knowledge/experience. I would think that it is possible to run both methods of authentication on the same set of servers (different documents, of course), but I can't get it to work. Has anyone else experienced problems (or been successful) at setting something like this up?

Thanks.

[dde]

With one QVS, yes that's possible.  I'm not sure it would be stable with a single IIS though, I would have thought you'd need one for each authentication type (both can point at the same QVS).  This is because for ticketing you'd normally set QvAjaxZfc to anonymous but not for the other authentication.

[#3]

Thanks for the reply - I created a copy of that folder (I called it QvAjaxZfcBa) and edited all the files I could see relating to the broken application to reflect the different URL path. I created a new Application Pool and user in IIS for this new site and I do get prompted for a userid/password.

The really strange thing that happens is once the access point is displayed and I see the documents to chose from, if I mouse over the document, it shows the URL for the document and the URL includes the QvAjaxZfcBa as I would expect. However, when I click on the document to open it, OK the popups described in the original post, the URL that then remains in the browser is incorrect in that the Ba is missing from the end QvAjaxZfc. It is almost like I missed editing a file our changing a setting somewhere, and can't figure out where.

Thoughts???

[Bill_Britt]

There is a lot of stuff that is hard coded to the QvAjaxZfc directory. So even if you rename it the files inside still points to the orginal folder. I have not tried it but I think your best bet is to create another website and then rebuild the virtual folders to point to the orginal folders.

Bill

[#5 · Accepted solution]

Didn't get it to work, but got the work to SSO enable the remaining app so the question is OBE at the moment....