When AllowUnsafeUpdates doesn't do "it"....

Hi,

My name is Jonas and I work here at Bamboo as an Architect. I will try to share some of the solutions we have found to the daily "challenges" of working with SharePoint.

If you have ever tried do do the "forbidden" and update SharePoint state on a HTTP GET request you have already found the AllowUnsafeUpdates property. It's available both on the SPSite and SPWeb objects. We ran into an issue trying to update a Feature property on a GET request. The feature had site scope so we assumed that setting AllowUnsafeUpdates to true on the site before updating the property would solve the problem.

The problem was it didn't help.... So we thought, how does the ObjectModel know what type of request it is? By checking the HttpContext. Fortunately you can write to the HttpContect.Current property so we decided to set it to null before calling Update and then set it back like this:

This will take care of the "problem". I don't really want to promote this, since it's better to never update state on a GET request. But the technique is usable for all the places in the ObjectModel where there are security checks against the HttpContext. Now in version 3 we have the RunWithElevatedPrivileges method but it doesn't work all the time and if you are still on WSS2 this can be quite useful. Instead of creating a new AppDomain and run the code as described here, Advanced coding technique: using AppDomains to get past OM limitations you can revert to the Application pool account and reset the context.

So here's some classes you can use:

Reset the Context:

And put them together for WSS2:

Now you can use it like this:

Update:

Here you can find some in depth explanation of how AllowUnsafeUpdates works.

http://hristopavlov.wordpress.com/2008/05/16/what-you-need-to-know-about-allowunsafeupdates/

/Jonas