Context Sensitive Webhelp behind a Site Login not working

[MJDomask]

Greetings, all.

We're having a problem getting context-sensitive help to work on sites where users must log in to view the help files. Here's the basic workflow:

1. Users press F1 in the program.
   
2. Development's magic happens and a web browser launches with a URL based on the current program screen. The URL uses this format: www.company.com/documentation/programhelp_csh.htm#arguments-for-CSH
   
3. The browser goes to the URL. Programhelp_csh.htm does its magic and tries to load another URL with the following format: www.company.com/documentation/programhelp.htm#document.htm.
   
4. The browser loads the requested page and hits our security tags, which redirects to the login page.
   
5. The redirect appends the requested URL to the login URL so that it can take you to the correct page. But, it removes the # sign and everything after. So, users end up going to the help file home page, not the page launced via CSH.

I talked to our web developers about this issue, and they say it's a basic problem with the URL formatting, not with the login process. To quote them:

quote:

---

Based on what we see, this is not possible – as query_string in a URL only accepts a “?”. If you do use this method for other pages, I will need to know where to find the pages so that we can research them.

This isn’t an “us” issue, it is a normal URL string pass, so we don’t have a method to bypass it.

---

Is there any kind of workaround we can use that will make the context-sensitive help work? I can't quite believe that the RoboHelp devs would use a symbol (#) that wouldn't work if kept behind a login. Is there some way others have found to either change the # sign to something else (like a ?) or use that query_string to keep the # and everything after it?

Thanks, all!

[Linux Rules]

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?

Regards,
GEWB

[MJDomask]

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.).

[Linux Rules]

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?

Can you post your call-to-Help javascript for us to review?

Regards,
GEWB

[MJDomask]

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.

What exactly do you mean by the call-to-help javascript? Sorry to make you ask so many questions; they have the content guy researching the tech problem.

[Linux Rules]

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.

Regards,
GEWB

[MJDomask]

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):
http://www.companyname.com/doc_central/help/help_csh.htm#topicId=TOPIC,withnavpane=true.

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):
https://www.companyname.com/Apps/Portal/Login/LoginPage.aspx?/doc_central/help/help.htm.

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.

[Linux Rules]

Understood.

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.

Regards,
GEWB

[MJDomask]

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.