Home > SharePoint Development > ThreadAbortException, Access Denied and OpenWeb()

ThreadAbortException, Access Denied and OpenWeb()

Recently I encountered issues with the SPSite.OpenWeb() method that have revealed some interesting behaviour on the part of SharePoint.

I was working with a web part that attempted to instantiate an SPWeb object for a site using the SPSite.OpenWeb() method in the context of the current user.  It was anticipated that if the user didn’t have permissions on the site, then an UnauthorizedAccessException would be thrown.

// this throws an UnauthorizedAccessException if the
// current user doesn't have access
SPWeb web = site.OpenWeb(webID);

Sure enough, an UnauthorizedAccessException is thrown for this statement and was handled in the code.

  // this throws an UnauthorizedAccessException if the
  // current user doesn't have access
  SPWeb web = site.OpenWeb(siteID);
  // user doesn't have access - exception handling code// some other code

Unfortunately, the SharePoint runtime also aborted the thread and caused a ThreadAbortException to be thrown immediately after the executing the contents of the catch block for the UnauthorizedAccessException.  Thus the “some other code” in the above example was never executed.

The net result of all this was that the user was presented with the SharePoint “Access Denied” page – even though the UnauthorizedAccessException was handled it somehow managed to propogate up the stack, presumably thanks to the thread being aborted.

The solution to this problem was to disable the unauthorised access exception handling for the site collection for the duration of the method:

// the standard SharePoint access denied exception
// handling should be disabled for the duration of this method
currentWeb.Site.CatchAccessDeniedException = false;

This permitted the method to handle the UnauthorizedAccessException without SharePoint causing the thread to be aborted.

Note: care has to be taken to ensure that this setting is changed back to its original value before the method exits.

Enter the weirdness

The situation above makes some degree of sense; although one can argue the merit of SharePoint aborting a thread which throws an UnauthorizedAccessException, we’ll take that as granted.

What is very confusing, however, is that immediately after aborting the thread, SharePoint then created another instance of the object responsible for creating the list of sites and this ran to completion still throwing UnauthorizedAccessExceptions for each site the user did not have access to but without throwing another ThreadAbortException.  This was exactly the same code, run in the same context, and yet exhibited quite different behaviour.

When the thread was aborted, why would SharePoint chose to create a new thread, re-run the same code and permit a different outcome?  Answers on a postcard to…

  1. Ben
    May 1, 2009 at 4:57 am

    This saved me after a day of searching high and low for a reason my custom SiteMapProvider was resulting in a SharePoint “Access Denied” page.

    May those other poor souls wandering the web for answers find their way here.

  2. Tobias
    September 30, 2009 at 11:13 am

    Thanks man!!
    Helped me also – pretty hard to find!
    Keep on this great work!

  3. Mikkel
    January 7, 2010 at 9:17 am

    Thank you – thank you – and thank you!

    You saved my day. And ~5000 users of our intranet – all getting access denied, because the code from our supplier wasn’t tested good enough 🙂

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: