Secure and Nonsecure in SharePoint

This page contains both secure and nonsecure items

Since you may be running SharePoint in a secure (HTTPS) environment, such as for a corporate intranet, you may encounter this popup warning message from time to time. Of course, it’s not actually an error message, but users will find it annoying and may regard it as an error.

More often than not it’s something simple, like an image pulled in from an external nonsecure site, or an iframe pulling in a nonsecure site. Sometimes though, it’s just plain weird and tough to uncover. Here are a few i’ve run into…

1. The Menu control

On one page we had a custom web part, and the web part happened to use a Menu control. It contained one visible node, and when a user hovers over the node a flyout appears with the subnodes. We found that in IE6 browsers, when the user would hover over the visible node in the Menu control, the "secure and nonsecure" warning popup would appear. It didn’t seem to matter whether the user would select "Yes" or "No", the control would end up working fine.

This was maddening to resolve, but I eventually ran into the explanation from Jerry Ormon at MS. It seems that the Menu control uses a hidden iframe, which points to "about:blank", which IE6 sees as nonsecure. http://support.microsoft.com/kb/910444 Thankfully, it’s pretty simple to resolve – just register a startup script that overrides the iframe URL with the blank.htm file that lives in the _layouts directory.

Add something like this code to your web part’s Render override:

string ie6fixJS = menuControl.ClientID + "_Data.iframeUrl=’/_layouts/blank.htm’;";

Page.ClientScript.RegisterStartupScript(typeof(this), "MenuHttpsWorkaround_jll", ie6fixJS, true);

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Note that we did not see this behavior with IE7, only IE6.

1. Redirect in dropdown OnSelect event

Again, with IE6 only. We didn’t see this problem in IE7.

We have a page that has a dropdown list, allowing the user to select a project name. When a selection is made in the dropdown, the server-side event handler redirects the user to the proper SharePoint Publishing subsite. Of course, since it’s a SharePoint Publishing site, we’re not redirecting directly to a page, but to the site’s URL, such as https://moss/subsite1. As you know from experience, when you hit the site’s URL, SharePoint will redirect you to the welcome page of that site, perhaps https://moss/subsite1/Pages/home.aspx. This is where it gets nasty.

SharePoint handles that welcome page redirect by issuing 301 responses, which essentially tells your browser to make another request to the full welcome page URL. When the redirect happens in the course of an OnSelect event from a dropdown list, you’ll find that one of the 301’s issued by the server is nonsecure (HTTP instead of HTTPS). Yuck. You have a couple of options at this point.

First, you can change your redirect code to go to the full welcome page URL. You can do this pretty easily by getting an PublishingWeb object of the site you’re redirecting to, then inspecting that object’s DefaultPage property.

Another option is to not do a server-side Response.Redirect at all, but use the old HTML META Refresh method:

Response.AppendHeader("Refresh", "0; URL=" + url);

This will cause the page to post back, then add a tag to the response page that will instruct the browser to redirect to the URL in the tag. Problem solved.

1. RSS Feeds

This one can be a problem in IE6 or IE7.

Your users may find the RSS Viewer web part to be very useful – and it is for the most part. But when you’re in an HTTPS secure environment, and a user points the RSS Viewer at some external feed, the data returned by that feed may contain embedded HTTP resources, such as an image tag with it’s source pulling in from a nonsecure site:

<IMG SRC="http://www.somesite.com/demo.jpg" />

Here’s a fairly simple quick’n’dirty workaround… create a new page in the _layouts directory, called something like rssFilter.aspx. The page will get the RSS feed and then parse out wherever it sees a SRC property with a non-secure value. It then re-serves the updated feed. Now, train the users to point the RSS Viewer to:

/_layouts/rssFilter.aspx?rssUrl=<rss url>

I’m sure there are other solutions to the above problems, but these worked nicely for us.