A Co-Worker and I recently stumbled upon something very interesting in terms of redirecting links within a single SharePoint Collaboration Portal. It all started out with us trying to move a separate site collection located under a managed path, to just a simple sub-site beneath our Companys Intranet SharePoint Portal, using Export/Import. Basically we have about 40 site collections beneath our main Portal located under the managed path of ’sites’. So the site collection we wanted to move was located at http://<portal>/sites/<site collection> and we wanted to move it to just http://<portal>/<site collection>.
The problem is, we cannot use a physical or virtual directory in IIS to redirect the old location to the new because of the fact that SharePoint wants to ‘manage’ the directory ’sites’ via the ’sites’ wildcard inclusion on the Manage Path Central Admin Page. If we simply put a physical directory ’sites’ beneath our http://<portal> our 39 other sites listed beneath the ’sites’ directory are no longer picked up my SharePoint. We even went as far as listing each and every one of the other 39 sites as explicit inclusions under Managed Paths(ex. /sites/site1, /sites/site2 etc) then create a virtual directory for ’sites’ and try to redirect a sub folder under that. This was causing us to see all sorts of strange errors.
In testing out different ways to redirect the site using IIS, we noticed that anytime SharePoint was picking up a URL that didnt actually exist(ex. http://<portal>/foobar), it would try to redirect the URL with the ’spsredirect.aspx’ page. Because SharePoint doesnt have record of the site ever having been at that location, sharepoint just sends you to a completely blank page with the URL of http://<portal>/_layouts/spsredirect.aspx?oldUrl=http%3A%2F%2Fportal%2Ffoobar.
The next thing we did was we started to investigate what could be done in terms of ‘SharePoint Redirects’ and we came across a few interesting blog posts by Joel O and Lapointe. Joel O seems to first bring up the ‘Secret’ list titled “Upgrade Area Url Mapping” located at the following location of any upgraded SharePoint Portal Site: http://<portal>/Lists/98d3057cd9024c27b2007643c1. It is then again mentioned in Lapointes blog about STSADM custom extensions. On any upgraded portal site, it is always the same name at the same hard-coded location(98d3057cd9024c27b2007643c1). Our first question upon discovering this was how did either of them discover this ‘Secret’ list and why in the world is it hard-coded with that crazy long URL. The second question we had was, what if we simply enter the information the list needs for a new entry?
What we learned was, this actually works! We clicked the ‘New’ button, and provided all of the values the form was looking for. This redirect functionality works wonderfully because it redirects every single item beneath the site we re-located to its brand new location. So for example, we have a document stored at the following location: http://<portal>/sites/<site collection name>/Documents/Book1.xslx, it would automatically redirect you to the new location(http://<portal>/<site name>/Documents/Book1.xslx). The only thing this redirect doesnt seem to cover is anything beneath the ‘_layouts’ folder.
It appeared to us that the ’spsredirect.aspx’ page does some sort of look-up to this ‘Secret’ List to work its magic. So we then asked ourselves, what if we placed an ‘Upgrade Area Url Mapping’ lists on a site that has not been upgraded? At first we tried to just create a new custom list with all the same columns and this just did not work. Next, we actually saved the existing one as a list template, then imported the template into another site, created a new list named “98d3057cd9024c27b2007643c1″ and this did work! We now have the means to re-direct users around our newly created collaboration portal using this list.
After all is said and done, we havent done much testing around to what extent this works(deeper or complex URLs). And to be honest, I would think that if this works as well I think it does, I’m not quite sure why this list wasnt made accessible from the root of a collaboration portal(regardless of whether or not upgraded) as a simple means for admins to re-direct users within their site. Microsoft must have hidden this list for a reason. What this reason is, seems to be a mystery. I guess since we are going to actually use this re-direct option on our Company Intranet, only time will tell.
More importantly, how can I use this exploit to make money. I will wait for your next post, which will hopefully contain a full tutorial.
cocobolo
February 8th, 2008