IE security error opening Web Help

booey · Post by **booey** » Wed May 06, 2009 9:27 pm

I am just trying out a Web help build. When i open the default.htm page I get an IE error "This page is accessing information that is not under its control. This poses a security risk. Do you want to continue." Now this is a common error and can be corrected by changing the IE security setting to allow cross domain data access. But I dont know what is causing this in the Web Help default page but it seems to co-incide with the frames being looded into the frameset. Does anyone have any suggestions as we cant tell all our users to change their browser settings.

Post by **RamonS** » Thu May 07, 2009 4:27 am

Is the help stored locally? If yes, do you have MOTW enabled? If not, do you have MOTW disabled? Other than that, I can only recommend using a real web browser. IE is the only "browser" that has such issues.

Mr Tagomi · Post by **Mr Tagomi** » Fri Aug 28, 2009 4:02 am

We had a recent security audit of a browser-based product that uses a Webhelp system.

The auditors flagged cross-domain navigation as a security threat (in IE7 and lower).

None of my colleagues has ever seen this flagged as a threat before. Our temporary solution is to deploy the html pages without the frameset, but we need a better solution in the long term.

Details of how to reproduce the issue are as follows.

1. In Security Settings, set Navigate sub-frames across different domains to Enable.
2. Open your webhelp in one tab.
3. Open a html file in another tab containing a link to somewhere on the net.
e.g. use this:

<HTML>
<h1>Frame Spoofing POC</h1>
<a href="http://www.google.com" target="body">Click this link</a>
</HTML>

4. Click the link in the html file
5. Go back to your help file. The topic frame in the webhelp will now show the web page you clicked in the other tab.

That is, IE will allow the html file to open its hyperlink in the â€œbodyâ€ frame of the neighboring help file tab.

Does not seem to be a problem in Firefox.

Is there any talk of Flare introducing a patch to eliminate this issue?

Post by **RamonS** » Fri Aug 28, 2009 9:52 am

Did you file a bug report?

Mr Tagomi · Post by **Mr Tagomi** » Mon Aug 31, 2009 7:43 am

Yes - apologies, I should have done that before resorting to the forum. It's logged now.

GlennV · Post by **GlennV** » Wed Oct 14, 2009 5:48 pm

I'm having the same issue.

Is there a fix for this yet?

Post by **RamonS** » Thu Oct 15, 2009 4:25 am

I don't know, but you can ask Microsoft. It is their browser that is the only one that puts a wrench in the gears.

GlennV · Post by **GlennV** » Thu Oct 15, 2009 8:09 am

IE is the most common browser out there and the only one our supported for our software products.

Is there nothing we can do in Flare to prevent this behaviour in IE?

Glenn

Post by **RamonS** » Thu Oct 15, 2009 9:20 am

I agree that for some odd reason IE is very popular, but I think it is a lot to ask from MadCap to work around flaws that clearly are in IE. These issues are the cost of doing business with Microsoft. Aside from that, when web pages are coded to standard the browser is likely irrelevant (unless you use IE where web standards are still considered optional) . So when pages only work with IE then the pages are not properly coded.

Leaving the well deserved dissing of IE behind, you should file a bug report with MadCap. Maybe they will bend over backwards to make Flare work around the flaws of IE. The MadCappers are very nice people and I wouldn't be surprised if they try and succeed, but still, the problem is in IE, not Flare. So you might want to file a bug report with Microsoft as well.

Post by **Andrew** » Thu Oct 15, 2009 9:47 am

GlennV wrote:I'm having the same issue.

Is there a fix for this yet?

Theoretically, the fix from MadCap would be relatively straightforward, I'd imagine: simply stop trying to navigate / communicate cross-domain (or cross-protocol/port/etc.).

The question is, what functionality or capability does the help lose? If the loss of functionality is unacceptable, then it may require a workaround, or redesign, which is rather expensive. The more people who submit bugs, the more likely it will be fixed.

Post by **NorthEast** » Wed Oct 21, 2009 4:03 am

I've seen this too, I get the error message when opening the WebHelp (with no MOTW) from a network drive.

The interesting thing is that I don't get the message for WebHelp generated using Flare v4, it only occurs for WebHelp generated using v5.
So it seems whatever is causing the problem was introduced in v5, and so presumably could be fixed in Flare.

Post by **Andrew** » Wed Oct 21, 2009 10:17 am

Dave Lee wrote:I've seen this too, I get the error message when opening the WebHelp (with no MOTW) from a network drive.

The interesting thing is that I don't get the message for WebHelp generated using Flare v4, it only occurs for WebHelp generated using v5.
So it seems whatever is causing the problem was introduced in v5, and so presumably could be fixed in Flare.

Flare v4.2 has this problem, as well. We get it when accessing WebHelp from our network drives.

Post by **LTinker68** » Thu Oct 22, 2009 2:45 pm

How are you getting to it? Are you using Windows Explorer to navigate to the network drive then double-clicking on default.htm (or whatever you called it)? Or are you using a path in the URL (e.g., file:\\\M\HelpProjects\...)?

Post by **NorthEast** » Fri Oct 23, 2009 3:03 am

LTinker68 wrote:How are you getting to it? Are you using Windows Explorer to navigate to the network drive then double-clicking on default.htm (or whatever you called it)? Or are you using a path in the URL (e.g., file:\\\M\HelpProjects\...)?

For me, it happens whatever way I try - opening the htm file in Windows Explorer, entering the URL in Internet Explorer, or clicking on a link to it from another web page.

Post by **Andrew** » Fri Oct 23, 2009 4:46 am

Dave Lee wrote:
LTinker68 wrote:How are you getting to it? Are you using Windows Explorer to navigate to the network drive then double-clicking on default.htm (or whatever you called it)? Or are you using a path in the URL (e.g., file:\\\M\HelpProjects\...)?
For me, it happens whatever way I try - opening the htm file in Windows Explorer, entering the URL in Internet Explorer, or clicking on a link to it from another web page.

Same here. Typically, we use UNC naming: \\servername\share\folder\xyz.htm

sarahwilliams · Post by **sarahwilliams** » Fri Mar 05, 2010 11:48 am

I started getting this error Wednesday when I added a home icon to the toolbar that was going to go out to a separate site (but in the same domain). I had previosuly had the logo going to a separate site with no problems.

Once I got rid of the javascript for the OnClick window.open, the error stopped happening. I am using Flare v4.2.

I had to find an older version of the skin file and replace it - just removing the javascript didn't do it.

Hope that helps.
Sarah

lmhundley · Post by **lmhundley** » Tue Jul 27, 2010 4:23 pm

I am experiencing this security issue as of today.

MadCap has worked for us for 2+ years with no issue like this.

I am on IE8. This is my company's standard browser, so change to anything else is verboden, as would be compromising security.

Today, using the MadCap standard skin template, I customized our skin (for the first time). Very simple; some colors, but the big change was the logo.

Every time I build with the custom skin, I get this security error. And it happens 4 times, in concert with what appears to be the loading of the various frames of the Help app.

If I specify the default skin in my target file, I get no error messages and the app loads fine.

Before I submit a bug report, I thought I would try the forum to see if anyone else had this issue.

Oh, I also tried that 'Enable' of the IE option, then I don't get the error, but the app doesn't load either. I am assumming that there are some "higher power" security that is preventing it this time.

I am guessing that there is a file that is perhaps "across domains" (if this is evern the issue)? I thought one of the purposes of building the help app was to gather all files together so there would not be any domain to cross (again, if this is the issue). If I know what file, I could move it locally as long as I can adjust it's load. This may be more than the forum can answer, but I thought I would try.

Any thoughts (please no IE bashing; I have to work with what I am given)?

Tks in advance to those that reply,
Lew

Post by **RamonS** » Wed Jul 28, 2010 9:01 am

lmhundley wrote:I am on IE8. This is my company's standard browser, so change to anything else is verboden, as would be compromising security.

Sorry, I don't have a solution, but since when does IE not compromise security? IE is the most common entry way into a Windows system while any other browser puts up more obstacles. I wonder what the real reason is why it is "verboten".
Yea, OK, sorry, that was IE bashing, but c'mon....

Post by **LTinker68** » Wed Jul 28, 2010 9:09 am

lmhundley wrote:Oh, I also tried that 'Enable' of the IE option, then I don't get the error, but the app doesn't load either. I am assumming that there are some "higher power" security that is preventing it this time.

Do you mean you enabled the MOTW option? If so, were you running the help from your local computer, or was it running from a web server? If it was running from the web server, then having MOTW enabled could prevent the help from showing up. MOTW should only be enabled if the help is running on the local computer.

If you are running the help on a server -- and testing it on a server -- were there any changes made to the server that could be causing the problem? Any patches or anything?

Even though you said you have to use IE8, do you have Firefox or something else you can test with? Trying it in another browser might narrow down whether it's a Flare issue, web server issue, or IE8 issue. Plus you sometimes get better error messages from other browsers.

If you recreate the skin and re-add the JavaScript from scratch, does it work now? You mentioned you were using v4.2, so the changes to the skin as a result of v6 and the Feedback feature shouldn't be the problem, but maybe something else in the skin file got corrupted, which is why going back to a previous version worked.

lmhundley · Post by **lmhundley** » Wed Jul 28, 2010 9:39 am

RamonS wrote:
lmhundley wrote:I wonder what the real reason is why it is "verboten".
Yea, OK, sorry, that was IE bashing, but c'mon....

I swore I wasn't going to get into this whole "change browsers" thing, but then I thought, well, maybe a little education MIGHT tone it down in future conversations.

The reason "changing browsers" is not an option is that we have inhouse developed web-app software that 100+ people use, that is running very well on IE, and that has not been certified on any other browser. Because of lean-ness of our staff, both developers and users, we go with what we know works, for now,, and IE works. Unfortunately, documentation and help is not number one on the company's list jof making money processes, nor a reason to consider wholesale changes in how the business is operated.

IE a bad decision from the beginning? perhaps; I wasn't there and don't know the reasoning. I am not an IE fan. But we made it work, flaws and all.

As for verboden and security, I believe that speaks for itself. Our security is working. We haven't had breaches. Certainly not gonna mess with it now, especially for lowly help documents.

So when we reply to someone's 'cry' for help, let's try and keep in mind that there ARE business reasons that prevent the switch from X app to Y, and try and address the issue, not repeat the mantra we all know. (I was concerned about getting useful help here because of the previous posts on this subject that beat the IE horse to death; but on a whole, the rest of the suggestions are helpful, so I posted) If the only fix is to change browsers, then, as I will have to do if I don't come up with a workaround, I will have to go look at some other application for writing help docs that itself deals with IE issues, evern if they are IE's fault (and will have to give due consideration to straight text in notepad) cuz I ain't brinigng in the $$$.

And that is why I asked for no IE bashing...

Post by **RamonS** » Wed Jul 28, 2010 9:50 am

Alright...just wonder if that internal app would have been coded to web standards using any other browser should not be an issue. Aside from that, the word is "verboten", not "verboden".

lmhundley · Post by **lmhundley** » Wed Jul 28, 2010 10:04 am

isa,
A couple of things you point out are helpful. I had forgotten about the fix working only with local; I am running on a web server.

Someone else posted as being on 4.2. I should have included that I am on 6.1.0.

I hadn't thought about testing with Firefox (I was braindead when I first posted having chased that issue for hours). I will give it a go. However,

I have myself in a bigger prediciment now. I am getting javascript errors because of null xml data; at least that is what the error says. I think my changing and copying of files back and forth from my local to my web server have screwed something simple up. The help document doesn't give the IE error nor even display; I get a blank screen.

Can anyone tella what I am missing or doing wrong from the following (first part is snippet of js error; second part the lines from the code):

Message: 'null' is null or not an object
Line: 3578
Char: 1
Code: 0
URI: <EDITED OUT>/Help%20Files/PHTech%20SPD%20Help/Content/SkinSupport/MadCapAll.js

Message: 'null' is null or not an object
Line: 8300
Char: 1
Code: 0
URI: f<EDITED OUT>/Help%20Files/PHTech%20SPD%20Help/Content/SkinSupport/MadCapAll.js

Message: 'documentElement' is null or not an object
Line: 5796
Char: 1
Code: 0
URI: <EDITED OUT>/Help%20Files/PHTech%20SPD%20Help/Content/SkinSupport/MadCapAll.js

3578 =
var xmlHead=xmlDoc.getElementsByTagName("CatapultSkin")[0];

8300 =
var toolbarNode=xmlDoc.getElementsByTagName(nodeName)[0];

5796 =
var xmlHead=xmlDoc.documentElement;

Thanks
Lew

Post by **LTinker68** » Wed Jul 28, 2010 10:19 am

lmhundley wrote:So when we reply to someone's 'cry' for help, let's try and keep in mind that there ARE business reasons that prevent the switch from X app to Y, and try and address the issue, not repeat the mantra we all know. (I was concerned about getting useful help here because of the previous posts on this subject that beat the IE horse to death; but on a whole, the rest of the suggestions are helpful, so I posted)

Let me know the answers to my previous post.

Also, I had another couple of questions... You said you're on IE8. Have you been on IE8 awhile (and the help worked), or was that a recent install? And is everyone having the problem, or just you? (That might narrow down if it was a patch installed on your system or something else that was enabled/disabled on your system that wasn't done on someone else's.)

lmhundley · Post by **lmhundley** » Wed Jul 28, 2010 11:03 am

LTinker68 wrote:Let me know the answers to my previous post.

LTinker68 wrote:Do you mean you enabled the MOTW option? If so, were you running the help from your local computer, or was it running from a web server? If it was running from the web server, then having MOTW enabled could prevent the help from showing up. MOTW should only be enabled if the help is running on the local computer.

Not sure if I mean MOTW. I didn't find that specific acronym nor "Mark Of The Web" in the IE options, so I guessed. I fooled around with setting the option "Security/Micellaneous/Access data sources across domains". Additionally, if MOTW only helps locally, that is not my issue. Local works fine. it is when I am running from my network server that it errors, and now, gives me the js errors (which are probably something I caused trying different things to resolve the main issue).

LTinker68 wrote:If you are running the help on a server -- and testing it on a server -- were there any changes made to the server that could be causing the problem? Any patches or anything?

Server/test = Yes. Any changes = No. If I make the the skin parameter in the target "(default)" it works fine; all other skins give me the IE error messages. And the same for my new js issue; if skin is "(default)" my help works fine. anything else, I get the js errors.

LTinker68 wrote:Even though you said you have to use IE8, do you have Firefox or something else you can test with? Trying it in another browser might narrow down whether it's a Flare issue, web server issue, or IE8 issue. Plus you sometimes get better error messages from other browsers.

I will try this as soon as I finish this reply.

LTinker68 wrote:If you recreate the skin and re-add the JavaScript from scratch, does it work now? You mentioned you were using v4.2, so the changes to the skin as a result of v6 and the Feedback feature shouldn't be the problem, but maybe something else in the skin file got corrupted, which is why going back to a previous version worked.

I have recreated the skin, tried a new skin, edited in the Output directories that I have published, etc. Still get the issues, plus now the js issue. Not using 4.2. I am on 6.1.0. I sorta agree about the skin file corruption, although I believe it now to be something to do with the new skin code, because the "(default)" skin works (this is an internal skin; in the code rather than a skin file?).

LTinker68 wrote:Also, I had another couple of questions... You said you're on IE8. Have you been on IE8 awhile (and the help worked), or was that a recent install? And is everyone having the problem, or just you? (That might narrow down if it was a patch installed on your system or something else that was enabled/disabled on your system that wasn't done on someone else's.)

Been on IE8 since its release, and Flare and the help files it creates have worked wonderfully. The problems started when I created my own skin from a flare template. I have tried different templates too, most recent beign Robin and Futuristic from the gallery. I am the only Tech Writer, so I am the only one accessing this currently. I will try your suggestion and see if someone else can load the help file from the server. That is a good suggestion I hadn't thought of.

lmhundley · Post by **lmhundley** » Wed Jul 28, 2010 11:57 am

OK, so I think I have a handle on this now.

First, yes, it works fine with FireFox. But I haven't checked it's security settings so if I change them I might get the same issue, although perhaps not.

I tried Lisa's suggestion of trying it on another user's system, and it didn't get the js errors, but did get the 4 IE error message dialogs. So I took an extra step and checked the system's option "Security/Micellaneous/Access data sources across domains" and it was set to "Prompt". Mine, from fooling around with this yesterday, was set to "Disable" and I was getting the js errors. "LIGHTBULB OVER MY HEAD". I went back to my system, and changed my option setting to "Prompt" and the js errors are GONE! But the message errors are back. I changed the option again, but this time to "Enable", and now it works without js errors nor IE errors.

So now I am thinking that if I get js errors when I don't specify "Prompt", might they be the root cause of the IE message errors? That is, IE doesn't like those vars to be 'null'? It appears they are only 'null' for the custom skins, and not for the "(default") skin. Maybe if MC can fix this and set the vars to the same values as the "(default") skin, there will be no IE issue.

I think I have taken this as far as I can in the forum. On to the bug report. Lisa, thanks for the ideas. They led me to at least something I feel I can report and asked to be fixed, WITHOUT having to ask for a companywide change to a different browser. I appreciate your sticking with me on this. (now I just hope my deductions are correct).

MadCap Software Forums

IE security error opening Web Help

IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help

Re: IE security error opening Web Help