Search

Training Users

Users will need to be trained to use relative URL’s, or use the SharePoint link picker. The main reason for this is that if a user sets a link to http://admin.geeksinsuits.com/ca/default.aspx the link will not be rewritten correctly. Also if there are any references to images using the admin site they will get a 404 error.

Another thing to keep in mind is even though your current page is published and you can see all of the other parts of the page while editing, when anonymous some of these other parts might not be viewable. This is because you are authenticated, so double check the page anonymously as well just to make sure everything is published.

Use relative URL’s

Publish pages and approve to see changes anonymously

Publish and approve any documents or images in document library’s that will be linked to

Check pages as anonymous

Summary

This brings us to the end of my overly long “blog post”, hope this has been useful as this caused me a lot of personal pain trying to figure it out :). URL Rewriting isn’t as hard as you might have originally thought, you just need to know the ins and outs of how to set it up correctly and the pain points. But you do have to know how you want your site structured before thinking about applying this. Users will also need to understand how they need to create the content to ensure there are no authentication problems or bad hyperlinks.

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.

Go to IIS

Go to Geeks In Suits Public (or your extended internet site)

Double click on Authentication

Right click Anonymous Authentication and click Edit

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.

XSLT

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.

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

Edit the Search Core Results web part

Edit the XSLT by clicking on XSL Editor under Display Properties. If you cant do this untick User Location Visualisation.

If you have another text editor i suggest copying this out to there for editing

Find <xsl:template match=”Result”> (should be line 206)

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”>

<xsl:comment>

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

UpdateFriendlyURLS(id);

// 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;

}

}

</xsl:comment>

</script>

</xsl:template>

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>

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.

Delete the <xsl:choose> node so there is only an empty span

Replace both instances of this code with the following<a href=”{$url}” id=”{concat($currentId,’_URLlink’)}”> <xsl:value-of select=”url”/> </a>

If you had edited the code elsewhere copy this back into the XSL Editor on the web part, press save

OK on the web part properties window

Save and publish the page

Now go to the page anonymously via the internet extended site, the URL text will be re-written like the rest of the page

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.

Go to the public sites URL Rewrite rules

Create the outbound rule to rewrite page URL’s

Click on Add Rule, select Blank rule under Outbound rules

Give the rule a name of “Rewrite html Urls into readable Urls” or something similar

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

Make the matching scope Response

Set Match the content within as A, Link and Area. This should cover most of our URL scenarios

Set the Pattern to ^(.*)/?/Pages/(.*)/?\.aspx(.*)/?$

Ignorethe case

Set the Action to Rewrite

Add the Value {R:1}/{R:2}{R:3}

Tick Stop processing of subsequent rules

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.

Turn Dynamic Compression off

Go to the public facing site and double click on Compression

Untick Enable dynamic content compression

Now refresh the page, everything should show up fine. If performance is going to be a problem read this post for a work around

To test that this has worked hover over the URL for California on the left. It now looks like the URL in the browser

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.

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.

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…

Write our first rule for the pages library and file extension

Open IIS and navigate to the public facing site

Double click on URL Rewrite

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

Set the Name to “Rewrite pages and file extension” or something similar

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.

Tick Ignore Case

Make sure the action is on Rewrite

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

Tick Stop processing of subsequent rules, if this matches we don’t need to process any more rules

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.

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 ^.*?[^/]+\.[^/]+$

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.

Go to the IIS Rewrite module and add another blank rule

Name the rule “Rewrite Default Welcome Page”

Set the Pattern as ^(.*/)?$

Ignore the case

Set the rewrite URL as {R:1}Pages/default.aspx

Stop processing of subsequent rules

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.

Go to the list of incoming rules and select the “Rewrite Default Welcome Page” rule. Click on Move up

If you get a prompt warning about the inheritance of the rewrite module click yes

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.

Go into central admin and create a new site

Leave the authentication as classic mode

Give the site a name, something which will indicate that it is the administrative site

Set the port to 80 and add the host header, something specific for editing the site, e.g. admin.geeksinsuits.com

Under security make sure Allow Anonymous is set to No

Change or fill out other fields as needed

Create the site collection

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)

Give the Site Collection a useful title

For the template select Publishing Portal under the Publishing tab

Enter the Primary and Secondary Admins

Add the new site to the hosts file

Extend the web app with an Internet Zone

Go to Application Management and highlight the admin site

Click on Extend

Give the extension a descriptive name such as “geeks in suits public”

Set the port to 80

Make sure the Security Configuration has Allow Anonymous set to Yes

Under Public URL set the Zone to Internet

Add the new zone to the hosts file

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.

Go to the extended site and log in (geeksinsuits.com)

Click on Site Actions, Site Permissions

Set the Anonymous Access to Entire Web site

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”.

Create our sub sites

Firstly we are going to create another site for California. Go to the admin site, site settings and create site

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.

Planning

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.

geeksinsuits.com/pages/folder/page.aspx

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.