These forums are read-only and considered to be an archive. Please use the new Community for future interaction and posts.

IE 6 error: This page contains secured and unsecured items

I've been running FileVista on an SSL secured website for about a year now and am not sure if this is something that just started happening (our customers haven't said anything) but I noticed after logging in and selecting the upload file option I'm getting a "this page contains both secured and unsecured items" message.   If I answer "no" to the prompt it brings up the upload dialog and works fine.

I've verified in IIS the website is fully secured/requires a secure connection, and all other functions work correctly and don't bring up that message.  I also viewed the IIS logs to see if I could see any calls being made to "HTTP" but don't see anything.  

Interestingly, the message is not displayed in IE7, IE8, or Firefox... only in IE6.  I've tested it on another workstation with IE6 and am able to recreate the message so it doesn't appear to be machine specific.   Machines used are on XP SP2.

I know I can disable this message in IE (mixed content setting) but that's not something I can tell our customers to do.  I'd like to try and get this resolved as the message gives them the impression their data is not secured.

I'm on FileVista version 3.5, website is running Windows Server 2003, IIS 6.0.

Any thoughts/ideas?
Ben 8/28/2009 2:34 PM
Please edit FileVistaControl\upload.aspx and find this text (line 20):

 <iframe name="frameUpload" src="javascript:false;" ...

Change the src attribute to an existing file such as

 <iframe name="frameUpload" src="images/loading.gif" ...

Let me know the result.
Cem Alacayir 9/4/2009 7:21 PM
Thanks for the reply.  I tried that and am still getting the message.  I did not restart IIS in between the changes, didn't think it was necessary but let me know if so.   I do have some additional information that may help shed some light.    

The website that contains the FileVista control is accessed a couple different ways, both using a subdomain name that points to our secure server.  ie: http://secure.ourwebsite.com will re-direct to https://www.ourwebsite.com/filevista.    One of the subdomains "masks" the forwarded web address so it never changes from "secure.ourwebsite.com", the other forwards and does not mask so the user will see https://www.ourwebsite.com/filevista.   

If accessed using the method that masks the forwarded address, the secure/unsecure message never appears.   However, if accessed by using the  non-masked method (or by directly typing in the full address), the secure/unsecure message appears when the upload button is clicked.

One final piece of information: I noticed the "Add" button on the upload dialog (lower left corner) contains a small document icon with a red "X" in it in the lower left corner of the button, the same thing you see if you access a website that has an image pointing to a dead link.  It's almost like the Add button is trying to access something that doesn't exist.  Perhaps this is the problem?

I hope that all makes sense.  Thanks again.
Ben F 9/8/2009 8:25 AM
re: the last paragraph above, the red "X" on the Add button appears regardless of how the site with the FileVista control is accessed.
Ben F 9/8/2009 8:27 AM
That red "X" means, the swf file is not loaded. This file should be loaded to enable Flash upload mode. 
Please check the existence of FileVista\FileVistaControl\scripts\swfupload\swfupload.swf
If it exists, I guess the url could not be found due to the redirection (or ssl).

You can temporarily disable Flash mode to prevent security message until you figure out the problem.
Open FileVista\App_Data\FileVista.config and add this line to force Browser mode (disable Flash mode):

  <add key="UploadMethod" value="Browser" />
Cem Alacayir 10/6/2009 3:18 AM
Thanks for the feedback Cem.  I did as instructed but am still getting the secured/unsecured error message.   Prior to making the change the red "X" was no longer appearing and the swfupload.swf file does exist.  Either way appears it's not a Flash issue after all.
Ben F 10/6/2009 9:23 AM