Tag Archives: Web Content Management

URL Rewriting and Anonymous Access with SharePoint – Part Five

23 Mar

Other Exceptions – Search and XSLT with Rewriting

There are some cases where the link will still be the full URL, if a user sets a link to “http://geeksinsuits.com/ca/pages/default.aspx” only the URL will be overwritten, not the actual text itself. So users need to name hyperlinks appropriately in a way that represents where the link is going, and not set the link text to the URL itself. An example of this would be using “About us” instead of “http://geeksinsuits.com/ca/pages/aboutus.aspx

In some cases this is unavoidable such as for search results. The XSLT will be using the actual page URL as the link text. The easiest way to get around this is by adding some JavaScript.

This post assumes that there is a search service application set up, the server standard site features have been enabled and there is a search page that is bringing back page results.

Search Core Results and Rewriting

There are a couple of tricks with search that might need to be configured. Firstly if your anonymous users cannot see search results (nothing shows up) and you can when your logged in you might not have set the right permissions on the extended site.

  1. Go to IIS
  2. Go to Geeks In Suits Public (or your extended internet site)
  3. Double click on Authentication
  4. Right click Anonymous Authentication and click Edit
  5. If the radio button has Specific User selected change it to Application pool identity. This got me earlier…

Secondly if you are using a search core results web part and are getting a 404 error when searching the page you may have to change the scopes drop down mode.

Edit the Search Box web part and set the Scopes Dropdown to “Do not show scopes dropdown, and default to target results page”. If this isn’t set an extra query string will be added onto the URL like below, this will result in a 404 error.



Most XSLT templates will show hyperlinks where the text is the URL. What we need to do to get around this is change the link on the client side as IIS cant change this content for us. We will step through making some changes to the standard search core results xslt. The same changes can apply to any XSLT however, you just need to add some JavaScript and call it via a template.

  1. The standard search XSLT shows the link text at the bottom of each result like below. We want this URL to look like the address bar in the browser
  2. Edit the Search Core Results web part
  3. Edit the XSLT by clicking on XSL Editor under Display Properties. If you cant do this untick User Location Visualisation.
  4. If you have another text editor i suggest copying this out to there for editing
  5. Find <xsl:template match=”Result”> (should be line 206)
  6. After the end of this template (line 415) add the below template and javascript. We will be able to call this template from anywhere in the XSLT<xsl:template name=”ReWriteURL”><xsl:param name=”currentId” /><script type=”text/javascript”>


    var id = ‘<xsl:value-of select=”$currentId” />’;


    // javascript for replacing hyperlinks innertext to friendly urls, but only based on the url

    // that has already been set, so it doesnt matter if it has been re-written or not

    function UpdateFriendlyURLS(id)


    var obj = document.getElementById(id);

    if (obj != null)


    obj.innerHTML = obj.href;






  7. Now we need to call the template after the result has been read out. Just before the result template ends add the template call for the javascript (just before line 415), this will pass in the ID of the current result link and change the URL text.<xsl:call-template name=”ReWriteURL”><xsl:with-param name=”currentId” select=”concat($currentId,’_URLlink’)”/></xsl:call-template>
  8. Now all we need is a hyperlink that has the right ID for our JavaScript to grab and change. In the standard Search Core Results XSLT there are two places, line 274 and line 389.
  9. Delete the <xsl:choose> node so there is only an empty span
  10. Replace both instances of this code with the following<a href=”{$url}” id=”{concat($currentId,’_URLlink’)}”> <xsl:value-of select=”url”/> </a>
  11. If you had edited the code elsewhere copy this back into the XSL Editor on the web part, press save
  12. OK on the web part properties window
  13. Save and publish the page
  14. Now go to the page anonymously via the internet extended site, the URL text will be re-written like the rest of the page

Cool, what now? Next Post… (Summary yay!)


URL Rewriting and Anonymous Access with SharePoint – Part Four

23 Mar

Outgoing Rules

Our URL’s look good now when we are coming into the site, but what about navigating around the site? We could rewrite the SharePoint links to the pretty URL’s by accepting the full URL and changing it after it is clicked e.g. http://geeksinsuits.com/CA/Pages/Default.aspx will be clicked and then rewritten into http://geeksinsuits.com/CA/Default (this was an optional step earlier). But this means our users can see URL’s that are inconsistent with the actual URL we are using. To get around this we will make an outgoing rule that will rewrite the links on the page.

  1. Go to the public sites URL Rewrite rules
  2. Create the outbound rule to rewrite page URL’s
    1. Click on Add Rule, select Blank rule under Outbound rules
    2. Give the rule a name of “Rewrite html Urls into readable Urls” or something similar
    3. Create a Precondition. Give it the Name “IsHTML”, leave Using as Regular Expressions. Add a condition With the Condition Input set to {RESPONSE_CONTENT_TYPE}. Leave the input string as Matches the Pattern. Set the Pattern to ^text/html
    4. Make the matching scope Response
    5. Set Match the content within as A, Link and Area. This should cover most of our URL scenarios
    6. Set the Pattern to ^(.*)/?/Pages/(.*)/?\.aspx(.*)/?$
    7. Ignorethe case
    8. Set the Action to Rewrite
    9. Add the Value {R:1}/{R:2}{R:3}
    10. Tick Stop processing of subsequent rules
  3. Go to the main page. You will either not see anything or you will get a 500 error. The reason for this is that Dynamic Compression is turned on and the outbound rewriting only works with un compressed responses.
  4. Turn Dynamic Compression off
    1. Go to the public facing site and double click on Compression
    2. Untick Enable dynamic content compression
  5. Now refresh the page, everything should show up fine. If performance is going to be a problem read this post for a work around
  6. To test that this has worked hover over the URL for California on the left. It now looks like the URL in the browser

For more information on Outbound rules click here.

Kool, anything else I need to think about? Next Post… (URL Rewriting with Search and XSLT)

URL Rewriting and Anonymous Access with SharePoint – Part Three

23 Mar

IIS 7 Re-Write Module

At the moment our URL looks like http://geeksinsuits.com/CA/Pages/default.aspx and we want it to look like http://geeksinsuits.com/CA/default. Before we can do anything further we need to download and install the IIS7 Re-Write module from here.

The IIS Rewrite module uses regular expressions to match patterns and split the URL into bits that we can rewrite what we need back in. Regular expressions (regex) can be hard to pick up, but you don’t need to be an expert, I’m certainly not. Trial and error work OK as well. Here’s a reference for the basics here.

  1. Make sure the page we will be testing with is published and can be accessed anonymously so if there are problems with the re-writing logic we know it’s not an anonymous problem. As I said earlier the easiest way of testing this is by having two browsers, IE for content editing and perhaps Firefox for viewing the anonymous site.
    1. Go to http://admin.geeksinsuits.com/CA/
    2. Click on Site Actions, View all Site Content and then Pages. This will show us what is published to the public
    3. If the page is still in draft it will need to be published and approved otherwise we will get a 404 error. Changes will only be picked up anonymously if they are again published and approved
    4. Now that we have a published page browse to http://geeksinsuits.com/CA/pages/default.aspx. This will be our page for testing the re-writing on

Incoming Rules

There are two incoming rules we want to have, one will be accepting the URL without the pages library and file extension, the other rewriting the default / welcome page for the site collections. Another optional rule is to rewrite SharePoint’s URL’s into our shortened URL’s.

NOTE:  If after following the below steps you continuously get asked for credentials, try re-opening the browser. If this does not work, before spending lots of time trouble shooting, try re-installing the re-write module as this can sometimes become corrupted and not work somehow…

  1. Write our first rule for the pages library and file extension
    1. Open IIS and navigate to the public facing site
    2. Double click on URL Rewrite
    3. There will be two empty lists, incoming rules and outgoing rules. For now we will only focus on incoming rules. Click on Add Rules and select Blank Rule
    4. Set the Name to “Rewrite pages and file extension” or something similar
    5. The first rule we will add will allow us to navigate to http://geeksinsuits.com/CA/pages/default.aspx as http://geeksinsuits.com/CA /default.
    6. In the Pattern field add ^(.*?[^/]+)/(.*?)$
      To test if the pattern is going to work click on test pattern and add the URL you want to check. Below I have entered the URL of our test page. You can see that it has been split into R:1 and R:2, we can now add the pages library in between here as well as the ending file extension. Again if your site is just one site collection follow Waldeks guide as he covers the rules for this scenario here.
    7. Tick Ignore Case
    8. Make sure the action is on Rewrite
    9. In the  Rewrite URL field add {R:1}/pages/{R:2}.aspx. This will piece together the actual URL of the page we are requesting
    10. Tick Stop processing of subsequent rules, if this matches we don’t need to process any more rules
    11. If you applied the changes and had a look at the page now it would look very messy. What we need to do is add a condition to ignore files so they aren’t rewritten.
    12. This rule was taken from Waldeks blog which steps through the same process. Under the conditions click on Add. For the condition input type {REQUEST_URI}.  Set the Check if input string field as Does Not Match the Pattern. Set the pattern to ^.*?[^/]+\.[^/]+$
    13. Apply the changes
    14. Now navigate to http://geeksinsuits.com/CA/default
  2. Because the pages library needs to have a default page and the site collection will point to this default page we need a rule to ensure this is being rewritten as well. This means http://geeksinsuits.com/ca/will go to the default page.
    1. Go to the IIS Rewrite module and add another blank rule
    2. Name the rule “Rewrite Default Welcome Page”
    3. Set the Pattern as ^(.*/)?$
    4. Ignore the case
    5. Set the rewrite URL as {R:1}Pages/default.aspx
    6. Stop processing of subsequent rules
    7. Apply the changes and try access http://geeksinsuits.com/CA/ you will get a 404 error. So we will move this rule up to the top so it gets processed first.
    8. Go to the list of incoming rules and select the “Rewrite Default Welcome Page” rule. Click on Move up
    9. If you get a prompt warning about the inheritance of the rewrite module click yes
    10. Go to http://geeksinsuits.com/CA/. This will load the default page
  3. Optional: Redirect SharePoint URL’s to readable URLs
    1. In case someone enters the full URL or there are links still hard coded with the pages library and .aspx extension we can rewrite this when the page is loaded.
    2. Create a new blank rule
    3. Set the name as “Redirect incoming sharepoint Url into readable Url” or something similar
    4. Set the pattern to ^(.*)/?/Pages/(.*)/?\.aspx(.*)/?$
    5. Ignore the case
    6. Change the action type to redirect
    7. Set the redirect URL to {R:1}/{R:2}{R:3}
    8. Make sure the redirect type if permanent
    9. Now go to http://geeksinsuits.com/CA/Pages/Default.aspx and it will change to http://geeksinsuits.com/CA/Default

Why is there still some ugly stuff? Next post… (Creating Outbound Rules for hyperlink URL’s)

URL Rewriting and Anonymous Access with SharePoint – Part Two

22 Mar

Creating a New Web App

This post will step through creating the web app, extending it to have an internet zone and setting up anonymous access on the internet zone.

  1. Go into central admin and create a new site
    1. Leave the authentication as classic mode
    2. Give the site a name, something which will indicate that it is the administrative site
    3. Set the port to 80 and add the host header, something specific for editing the site, e.g. admin.geeksinsuits.com
    4. Under security make sure Allow Anonymous is set to No
    5. Change or fill out other fields as needed
  2. Create the site collection
    1. After the web app has been created we need to make the top site collection, click on create site collection in the prompt that has popped up or go to Application Management and Create Site Collections (Make sure the right web app is selected)
    2. Give the Site Collection a useful title
    3. For the template select Publishing Portal under the Publishing tab
    4. Enter the Primary and Secondary Admins
  3. Add the new site to the hosts file
  4. Extend the web app with an Internet Zone
    1. Go to Application Management and highlight the admin site
    2. Click on Extend
    3. Give the extension a descriptive name such as “geeks in suits public”
    4. Set the port to 80
    5. Make sure the Security Configuration has Allow Anonymous set to Yes
    6. Under Public URL set the Zone to Internet
  5. Add the new zone to the hosts file
  6. Set anonymous permissions on the internet extended site. Even though we set Anonymous Access to Yes, we still need to allow anonymous access to the whole site.
    1. Go to the extended site and log in (geeksinsuits.com)
    2. Click on Site Actions, Site Permissions
    3. Set the Anonymous Access to Entire Web site
  7. To test if the site is working anonymously it is easiest to use another browser just to access the extended site. If you’re using a virtual machine you can point your local machines host file to the site on your virtual machine. You will be able to tell if your logged in or not by looking at the top right of the site, this should say “Sign In”.
  8. Create our sub sites
    1. Firstly we are going to create another site for California. Go to the admin site, site settings and create site
    2. Select the Publishing site template
    3. Set the title to California and the URL name to CA

Do the same for Washington and give it the URL name of WA

Ok so how do I do the fun rewriting stuff? Next post… (Installing Rewrite module and making Inbound Rules)

URL Rewriting and Anonymous Access with SharePoint – Part One

22 Mar

There are many useful blogs focusing on URL Rewriting for SharePoint but none cover everything in one go and it can be quite hard to piece together all of the information. This series of posts will talk you through creating a web app from scratch, setting up an anonymous internet extension, setting up pretty URL’s and getting around any problems along the way. The URL’s that we will end up with wont have the pages library or the .aspx extension. Just as a note here, I am using IIS 7.5 and SharePoint 2010.


The site structure will determine how the re-writing will work, so this needs to be done before implementing anything. There are two scenario’s I want to cover for a fictional product company called Geeks In Suits to illustrate how different the rewriting can work. Geeks In Suits are based in two states, Washington and California. The products and services they sell in these two regions are quite different. They either want to put all of their information into one pages library in one site collection, or have two sub sites, one for each state as the sites will grow bigger in the future.

The way that URL rewriting works is we need to take the URL coming in and change that back to a URL that SharePoint can understand. This means adding the pages library back into the URL and the .aspx extension back onto the end of the requested page. Below are our two scenarios.

Example 1: One Site Collection

If one site collection is used we have to place the /pages/ back into the URL and we always know where this is going to go, just after the main address of the site. Everything in between are folders or and a file name so we can just add .aspx onto the end.


Example 2: A Site Collection with sub sites

If we decide to use the main site collection just as a parent to inherit from and use two sub sites to hold the content we add another layer to the URL.

For example if our URL is geeksinsuits.com/CA/Folder/page where do we add the pages library? Our rules will have to have some type of knowledge about our URL before it is rewritten.

In this post I am going to go over Example two, Waldek has already covered the rules needed for example one very well here.

Anonymous Access

Public facing sites need to be accessed by anonymous users, but the site also needs to be maintained by the content editors. There are a few different ways that you can allow people to log into the site for the content editing, using a login link, having a login page that only the editors know about, having somewhere to click etc. We are going to extend the web app so it will have an internet zone. This will allow us to have two IIS websites that will be accessed separately but are still essentially the same site. This will also fix our problem with editors logging in as there will be two urls that can access the site, one needing authentication and the other being fully anonymous.

Interesting? Yes? Go to the Next Post (Creating a web app with an internet extension and setting up anonymous access)