This content has been marked as final. Show 8 replies
Welcome MJDomask -
I'm a bit confused (of course that's nothing new!) - you are posting in the WebHelp forum but your post references "CSH" which is not true HTML Help.
Also, is your application local (or on a "local" network) or is it Web based?
It's web-based help using the context sensitive help options in RoboHelp.
The application runs either as a local version or a "thin client" that works over the web, but both behave as if they were being run from the local machine (not browser-based, not run over terminal services, etc.).
OK, thanks. So, do I have the desired flow correct:
Local App > User calls Internet based Help > User logs into Web site > Web site validates user > Web site serves context Help page
What application / method is used for Web login and validation? Is login persistant? How long?
That's the desired flow, yes. The login page is a web form login, I'm guessing some kind of VB magic to query a database of user names/passwords and authenticate. It leaves a cookie on the client's machine that's valid until midnight, I think.
OK. A strange way to do things but to each their own.
Your desired method will be problematic at best. I would suggest a slightly different approach...when launching the application force a login to the Help server. That way the authentication is done and the cookie set before the user needs to access Help.
There may be other options - this is what came to mind first.
Oh, another idea...you posted:
"But, it [the redirect] removes the # sign and everything after"
I can't understand why that is happening. If it can not be avoided then you could process the login request, intercept the initial string, substitute another character/string for the # sign, redirect, then reassign back to the # sign to complete the call to Help. We do something similar in our Web based application.
This is actually the Plan B workaround for accessing help; we wanted users authenticated during program login, but that didn't make it into the program yet. So, we're forced to use our web portal security for the help file.
As to why it removes the # sign, I can only go by what the web guys tell me. Apparently, when the login script works its magic, it does some kind of query_string function to get the URL that the user actually wanted. So, the application launches the browser and goes to look for this URL (stage 1):
It finds that, does magic, and comes back with this URL (stage 2): http://www.companyname.com/doc_central/help/help.htm#TOPIC.htm.
This tries to load and runs into the login, which saves part of the URL it was looking for (stage 3):
The way our web guys explained it, the way they get the stuff after the ? mark is using that query_string command, which doesn't recognize anything after the # sign. I'm not sure if they can intercept the URL in stage 2 before it hits the login script and make the switch from # to something else.
Thanks for all the help, by the way. Also, my apologies for substituting in generic terms for real values; the company values confidentiality.
Have your Web guru check the login application valid characters and remove the hash sign from the "deny" list or add it to the "allow" list. He/she may not like the idea as the # sign could be used in a security breach attempt.
However, I would do a two stage approach. In your "stage 2" I would substitute an acceptable character or string for the # sign then at the end of your "stage 3" (after authentication/login) reassign the # for the substituted string in stage 2.
Thanks a bunch for the help. I'll have to talk to our web guru guys to see if there's a way to do this. I'm hoping I can find some way to change the way RoboHelp handles these things to make it work better, but just changing the symbol should work.