Determining what triggers an IE security dialog

I found myself working on a problem where IE was popping up the usual mixed-content secure/non-secure dialog:

We are using GWT/GXT so it wasn’t immediately clear what insecure content was being requested in the generated code.

To start with, I wanted to see if Firefox also reported the same problem:

(Yep). Starting with the low-hanging fruit, I used firebug to find out if there was any non-https requests being made in Firefox.  As it happened, we did have a non-https request being made. After fixing that, Firefox no longer complained about mixed-content. Sadly, IE still popped up the mixed-content dialog.

I figured that compiled GWT might be making different requests for Firefox and IE so following the advice here, I used an IE add on to make sure there weren’t different insecure requests being made in IE (there weren’t). That same discussion also suggested that using src=”javascript:void(0)” triggers the insecure flag, and using src=”//:” fixes that. Unfortunately, that also wasn’t our problem.

I then stumbled onto a very informative post from a blog about IE externals. Unfortunately, the problems mentioned in the blog proper weren’t the problems in our case. Apparently IE is more aggressive than Firefox in declaring that things are insecure, among them “about:”, “javascript:”, “res:”. Unfortunately, IE doesn’t tell you what it found that was insecure making it really difficult to track down in a GWT app.

The comments section had a good continuing discussion on the general topic of how to track down the mixed-content problem including solutions to some of the problems others encountered that I hadn’t seen anywhere else. I came across this bit of gold. After installing the add on, the mixed-content warning looked like this:

With this information, it was simple to track down the culprit. In our particular case, we were using a GXT ClippedImagePrototype to override some paging toolbar buttons. We used relative URLs to specify the location of the modified icons and this seemed to be the problem. I’m still not completely sure why IE thought we were using an “about:”. There was some discussion in the blog comments about why “about:” was reported but it didn’t sound like those cases applied to us.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply