The rogue character was simply a duplicate of one of the characters in the URL that was given me, that was obscured by the fact that the URL was created by concatenating some strings and variables. There was nothing wrong with the character itself (a single quote, I think) just there should only have been one of it.
Finishing my blog post on the topic is right up there on my to do list, it just needs some screen grabs and code snippets now.
The "Customized authentication v1.0" by Fredrik Lautrup and Michael Bienstein describes the architecture for authentications solutions using Web Clients for QV version 1.1.
Is there a corresponding document for solutions using OCX clients?
I know the OCX will be deprecated when Microsoft stops supporting OCX. But until QV supplies a replacement solution that can be embedded in desktop clients (non-web clients) ... I am looking for an OCX based solution.
1) Convert QVServer to using DMS authorization
2) Use QVEMC to manually add an authorized name (no windows account needed for this name) for a qvw, e.g. Frank
3) Request a ticket for Frank using as credentials a name/pswd for a windows account that exists on the machine hosting GetTicket.aspx
Then I am able to pass the folloiwng qvp to file open in the OCX
i.e. CTE+DMS ==>> qvp+ticket ==>> open qvw in OCX
I could not find anything in the QVServer Ref manual that says only DMS authorization is supported for CTE.
Is this the case?
My SSO Implementation with QV11.2 is working fine. But it's taking client's IP address instead of Server IP address.
Is that true SSO is working based on client's IP address?.
we are struggling with the exact same problem.
WebTicket gets created. I can get into the access point allright but opening a document brings the login screen. I can cancel the login screen and still get to the document ?
We are on QV 11 SR2.
Anyone has a solution for this ?
I would have thought the login page would be irrelevant, as the site would be set up to allow anonymous access, and then the token that was requested for a user would identify (and secure) that it is the same user then requesting the document.
Use the following url:
where hostname is the server hostname, webticket is the webticket generated for the user, and qvw_file the url encoded full path to the qvw on the server .