IE message with "nonsecure items"

Forum Moderators: open

Message Too Old, No Replies

IE message with "nonsecure items"

IE warning message with "nonsecure items"

octfan

7:27 pm on Oct 3, 2007 (gmt 0)

After deploying a new release, we are seeing some IE warning message saying "This page contains both secure and nonsecure items." Does anyone have any idea on how to fix it? (not just get rid of showing the message).

Following is what we have tried for debugging:

1. Check the urls of included files (e.g. gif, js, jpg). They are all from [,...] not http:// . To check that, we go to IE -> Tools -> Internet Options -> Settings -> View Files ... then check the "Internet Accress"

2. Check the source attribute in every js files.

3. Open the page in FireFox, check the HttpLiveHeaders for http://

Demaestro

7:42 pm on Oct 3, 2007 (gmt 0)

That almost always stems from something being called into a page that is at HTTPS:// from a HTTP:// location.

I know you said you looked but go into the code source and make sure that you are calling images and files from the https:// and not http://

Also your SSL cert could be specific to a single directory... if so make sure all files called into the page live in the secure directory.

Fotiman

8:35 pm on Oct 3, 2007 (gmt 0)

Another cause is if you have an iframe that does not have a src attribute, for example, if you are using an empty iframe as a shim to cover select boxes or using it in some programmatic way.

The solution: give your iframe a src value of 'javascript:false;'

Alternatively, you could use a src that points to a real HTML file containing "<html></html>", but the javascript:false; method should be more efficient (no additional request to the server).

Hope that helps.

octfan

8:49 pm on Oct 3, 2007 (gmt 0)

Thanks for the helps and quick response.

Regarding iframe, we are using div tag instead, as we have some issues with BEA portlet communication using iframe.

Regarding secure directory, we put the static contents (image and js)in a subdirectory in IIS web server, the dynamic contents (jsp, forms, etc) in an BEA app server. All requests go through the IIS, then to BEA.

In the source code, we use relative path. That is how we ensure static contents are from https:// and not http://

So far, I am thinking about that let the app server serves all the content, including static content, and see where I can get from there.

Thanks for the helps.

Fotiman

2:32 pm on Oct 4, 2007 (gmt 0)

If you use any third party JavaScript, it could be possible that those are creating iframes that you don't know about (to fix a bug in IE). Just to be clear, this iframe doesn't contain any content... it's only used as a layer behind some absolutely positioned elements. The reason is because in IE any <select> elements that are behind the absolutely positioned element will show through (no matter what z-index is used). The fix is to create an iframe layer behind your absolutely positioned elements, which prevents the select from showing through.

Also, you could try installing Ethereal [ethereal.com] to sniff the packets and examine all of the http and https requests to see what, if anything, is being requested that is not secure.

[edited by: Fotiman at 2:36 pm (utc) on Oct. 4, 2007]

octfan

2:36 pm on Oct 4, 2007 (gmt 0)

While looking the TCP packet, I don't see any insecure (i.e. http) links, but I don't see a few ACK failure or checksum error.

octfan

5:27 pm on Oct 4, 2007 (gmt 0)

Thanks for the helps. We have found the root cause.

In a javascript function, the src for an iframe (which is a temporary place holer as we don't use iframe in our jsp) is an empty string (i.e. ""). It should referred to certain physically existed file.

Before, we have a zero-byte html file, and make it as the src of an iframe. After we remove the file as we thought we don't it, we update the src of iframe. And the "nonsecure item" message starts to show up.

rocknbil

5:45 pm on Oct 4, 2007 (gmt 0)

Also for reference Google Analytics and the download URL's of Flash objects will cause this.

Fotiman

8:22 pm on Oct 4, 2007 (gmt 0)

The solution: give your iframe a src value of 'javascript:false;'