views:

1149

answers:

5

I have a WSS 3.0 system using SSL where every page is supposed to be served as https. Almost all pages do come out as https, but in certain cases I click on a link and that brings up an http version of a page (which does not load). In those cases I have to put the 's' in by hand to get the page to load. Places where this happens are:

  • /_layouts/newgrp.aspx : when I try to create a new group, it takes me to http://server/%5Flayouts/newgroup.aspx, although it should be https. The page does not load at http. It does load if I change the url by hand.
  • /_layouts/edtgrp.aspx : same thing as newgrp.aspx
  • if I go into a document library and view version history for a file, the URLs to the individual versions of that file are http. Interestingly, the browser status bar also indicates http when I hover over them (so it seems that SharePoint gets confused when it generates the links, rather than when I click on them)

To fix this, I have tried adding some javascript to the DOM that searches for instances of http and replaces them with https. This works in some cases, but there are some places where javascript can't reach, for example when SharePoint provides the target URL in response to a POST request, which I think is the case with newgrp/edtgrp.aspx.

I have also tried adding ISAPI filters to redirect pages from http to https. This seems to cause redirect loops, and in any case I'm not sure if such filters would preserve querystring or POST information.

Has anyone seen this problem?

Update: We have switched to ISA from Squid, and the problem continues in the version history, but not on new group or edit group. We have not seen any improvement yet from changing AAM settings.

Places where this is happening in ISA:

  • "Version History" under item in list or document library
  • "Manage Permissions" under item in list or document library
  • "Alert Me" under item in list or document library
  • "Add Users" menuitem in "People and Groups" page
  • "Group Settings" menuitem in "People and Groups" page
  • "Edit Group Quick Launch" menuitem in "People and Groups" page
  • "Set Up Groups" menuitem in "People and Groups" page
  • "List Settings" menuitem in "People and Groups" page
+3  A: 

Not sure if this is it, but have you checked your alternate access mappings to make sure they say https instead of http?

Kirk Liemohn
+1  A: 

I would echo the suggestion to check your Alternate Access Mappings. Is the SSL being done on the SharePoint Front Ends, or is it being done via a piece of dedicated SSL hardware?

Daniel McPherson
We are trying various configurations in the AAM. I am thinking this is not the main issue because the problem seems to happen only in some places. We have a Squid software reverse proxy, which I think is the source of the problem.
strongopinions
I would be pretty confident that it is indeed the source of the problem. Though that is not to say its not a bug in SharePoint. Its support for reverese proxies is, I understand, a little patchy.
Daniel McPherson
We are having similar issues using ISA. From what I can tell it could be an issue with the AAM.
Bob
A: 

Add a redirect in IIS from http to https. Every time you access that page it will redirect you to your https page instead.

I would also suggest placing WSS on another server to see if you have the same problems. If you don't, you might need to rebuild/migrate your stuff over.

Mitchell Skurnik
I don't think the redirect will work because I don't think it preserves your POST or querystring parameters.
strongopinions
+1  A: 

Use an HTTP Module to modify SharePoint's output so that links are always changed to https. Such a module can plug into IIS and modify the HTML of anything rendered. I've used this technique to make SharePoint XHTML compliant and it works well.

Even better, almost all of the work has already been done for you. The UrlRewritingNet module is open source and available for free download. It should work fine for your SharePoint site. This tool has great documentation and uses regular expressions to match which URLs to alter. It should be pretty easy to write one for your case, e.g. ^http://. There's also many more advanced options you can take advantage of if necessary.

If you'd prefer to write your own then there is a good article called Rewrite.NET -- A URL Rewriting Engine for .NET on the 15 Seconds site.

Finally, if you're using IIS 7 you could try its URL Rewrite Module. I've never used this myself and don't know if it works with SharePoint, but it's the most UI-driven solution available.

Alex Angas
I actually ended up doing something similar to this. I will post the details in a separate answer. I am going to award the answer to you but this still feels like a workaround and I think there has to be a way to make SharePoint do this by itself.
strongopinions
A: 

Alex answered this question with an approach that I think will generally work. Here is how I fixed this specifically.

It looks like when a SharePoint aspx page is loaded, it populates a javascript structure of type ContextInfo (defined in init.js), which is instantiated in the variable ctx. That structure has a member called httpRoot, which is later used in core.js to build menuitems in various dropdown.

This ctx.httpRoot is for some reason populated in javascript in the aspx files created by SharePoint with a line like this:

    ctx.HttpRoot = "http:\u002f\u002fsubdomain.domain.com";

Yes, it has Unicode slashes and it has http instead of https. I have no idea why. But, fixing this line of javascript seems to fix the problem.

I changed the line by adding a URL translation rule in ISA that converts http:\u002f\u002f\ to https:\u002f\u002f\ . I suspect that an HTTP module that makes the same replacement would also work. Or possibly some well placed javascript that reassigns the variable at some point.

I still believe this is not ideal and there must be a more appropriate way to fix these links.

strongopinions