It could just be coincidence that recently i’ve solved 2 tricky SharePoint dev problems using HTTPModules, or it could be a case of once you find a good solution to something, you try and shoehorn apply it to all other problems…. either way, I thought it would be worth going over the examples and why this approach is useful to developers who work with ‘product’ apps such as SharePoint.

Quick overview of HTTModule and HTTPHandler can be found here.

The benefits of using HTTPModules

A HTTPModule works well with 3rd party products as you do not have access to the source code and / or you are not able to change core files. You need some other way of hooking into the page event lifecycle. Of course there are many available ways of doing this already (Event Hooks, SharePoint Event Handlers, etc.) but sometimes these just don’t cut it.

See below for examples.

Example 1 – Custom Authorization Provider for SharePoint 2010

I’m working on a project where SharePoint will be a repository for storing wiki & blog sites and a few other web based structures, while the main application itself exists independent of SharePoint. This app has it’s own custom Authentication and Authorization processes which store all user session data in a custom database.

The Authentication piece of this is very interesting too as we are using a custom Claims Provider for SharePoint 2010 but that’s another blog post.

For the Authorization piece, we need a way to intercept each page request to the SharePoint environment and verify that the user has sufficient permissions to access this resource. Obviously, we don’t want to have to make this webservice call for each page request (or fractions of pages – some SharePoint pages i have seen can make over 30 separate authorization calls for different page controls on first load!!) so we need a way to verify user access level initially and then cache this for a period.

The initial road i went down here was to produce our own custom ‘AccessDenied.aspx’ page which all users would automatically reach if they attempt to access a resource they do not have permissions to. This worked really well as we could wait for the pipeline to finish processing and intercept the process at the very end when we were sure the auth had failed.

The problem with this is you can’t touch SharePoint default files. MS get very cross on support calls if you dare and tell you to go away until you put the system back the way it was. So i can’t hack into the ‘accessdenied’ page

This is where the HTTPModule came in. I initially thought I could jump in at the ‘AuthorizeRequest’ event of every page call so i could provide seamless authorization to the user. But because of the number of times this would be called (not just for pages but for page elements), I was very concerned about the detrimental effect this code might have on overall load times. I settled on combining both earlier ideas -  I can detect when the context URL contains ‘/_layouts/accessdenied.aspx’, insert some custom code for these requests only then redirect if the user passes our auth check!

Authorization Caching

The solution to the user auth caching is to add the user to the relevant SharePoint group with access level set, but in tandem, write a secure cookie (encrypted using machine key of server) to the client machine which has a hard expiration of 20 minutes (hard expiration to stop hackers indefinitely extending the life of a sliding session by maintaining an open connection by periodically pinging server).

Example 2 – Override Core SharePoint JavaScript functions

The majority of SharePoint’s javascript is called from a file called ‘core.js’ which is included in the MasterPages as a script link. The MS recommended approach is to create a custom Master page and change this link, but what if the page you want to modify is also a core SharePoint file (in this case ‘versions.aspx) and you can’t touch it to change the Master Page link? HTTPModule again! Detect this URL and forward the user on to your version of this page which calls the customised javascript file. Et voila.

Of course it’s never that simple – i had a lot of messing to do with relative URLs to get it to work but the principal is there.

Downsides to using HTTPModules

As the HTTPModule code will be called for every request through the page pipeline, poorly designed code can have a massive effect on performance. Think very carefully about what extra processing you are adding before doing it.