One of the options is called "Show Navigation Pane Link in Topics".
I do know that a year or two back, some sort of "cross site scripting vulnerability" was discovered, but I believe Adobe issued a patch shortly after the discovery that addressed it.
My guess here is that while it may look bad, what you are seeing is pretty innocuous and nothing to be concerned about.
OK, thanks for your info Rick.
Great! Thanks Peter.
We too are experiencing this problem and need to get it to turn off. I have looked at the past discussions surrounding this topic and it seems that this document.location.href code has something to do with breadcrumbs? I don't have breadcrumbs or the navigation pane link turned on anywhere in my system (using RH 10), so I am not too sure why RH is adding this code to all my topics.
Any help would be appreciated. I have a number of webhelp and webhelp pro systems and don't want to have to change every file in every generated help system with security code each time I generate and release. Peter's suggestion to multscreen HTML5 output is a good one, but the change would be a bit more wide reaching than just my help systems so at the moment not the immediate option.
I believe that this code checks whether there is a breadcrumb available on the current page. This code is added on generation. This is part of the generation process and I'm not sure if it can be changed.
Is it a potential risk? Is taking your car downtown a risk? I'm not a security expert, but this sounds a bit paranoia to me.
RoboHelp 10 WebHelp has changed the way it works and it uses safe cross-frame communication. That might be a solution for you. Otherwise the Multiscreen HTML5 output may help
Thank you Willam,
Do you know if it is just RH 10 Web Help that has this safe cross-frame communication? Does WebHelp Pro also have it? I am currently outputting to WebHelp Pro using RoboHelp 10.
As to your comment whether or not this code is a security risk or not, I do understand your point, however, as I have no control over what the customer perceives as a security risk in their highly secure and extremely regulated environment, I have little choice other than to try and fix the problem.
Nope, the code is still there in WebHelp Pro.
I understand that you have to live with your customer. Life could be so much easier ;-)
What you can try is using a find and replace in your output changing all occurances of
var strUrl = document.location.href;
var strUrl = "";
I don't believe it'll break anything (important). This may save you a major headache.