Ever seen this error message?
System.Exception: Microsoft.SharePoint.SPException: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.
It is usually related to a missing SharePoint FormDigest control, or updates to the DB on an HTTP GET request. You might hear people saying you should set AllowUnsafeUpdates to true, but in the case of a POST request that is not the best thing you could do. The best resource that you could ever read on the topic is written a while back (in 2008!) by a good friend of mine and ex colleague – Hristo Pavlov. These two posts are your best starting point if you want to understand what these items are for and how they achieve their purpose.
What You Need To Know About AllowUnsafeUpdates (Part 1)
What You Need To Know About AllowUnsafeUpdates (Part 2)
Generally speaking, AllowUnsafeUpdates = true on POST shouldn’t be required at all. I was working with my team on an HTTP Handler living in the SharePoint Layouts folder and it was failing with the security validation exception. In a typical ASPX web page you would include the SharePoint FormDigest control and SharePoint will handle it from there onwards:
<SharePoint:FormDigest runat=”server”/>
You will notice the output of this control is a hidden <input> like this one:
<input name=”__REQUESTDIGEST” id=”__REQUESTDIGEST” type=”hidden” value=”0xDA527A96…A23,22 Apr 2011 14:17:06 -0000″/>
SharePoint will use this control (in particular the parameter __REQUESTDIGEST) and validate the “FormDigest”. You can explicitly call the SPUtility.ValidateFormDigest() helper method achieves the same. (See Hristo’s blog posts for more info on how it works). It basically takes the __REQUESTDIGEST value and validates it on the request object.
But in an HTTP Handler you don’t have the <SharePoint:FormDigest /> control as there is no ASPX. Developers can get the handler working by setting AllowUnsafeUpdates on the SPWeb object, but this should be avoided when it could (see Hristo’s post on why it is not good). If you are making a POST request, pass in the __REQUESTDIGEST and make sure you call the SPUtility.ValidateFormDigest() method before you do any DB updates.
If you want to call your handler asynchronously with AJAX, lets say with jQuery, this adds another level of complexity. You have to pass in the __REQUESTDIGEST parameter for SPUtility.ValidateFormDigest() to succeed. I personally found documentation on the $.ajax jQuery method quite poor, but here is a JavaScript example on how to use it and pass the __REQUESTDIGEST <input/> value:
function UploadFileAsync() {
var listId = $(“input[id$=’hdnListID’]”).val();
$.ajax({
type: “POST”,
url: “/_layouts/Handlers/FileUpload.ashx?ListID=” + listId,
contentType: “application/x-www-form-urlencoded”,
data: “__REQUESTDIGEST=” + $(“#__REQUESTDIGEST”).val(),
timeout: 30000,
success: function (response) {
alert(response);
},
error: function (x, t, m) {
if (t === “timeout”) {
alert(“got timeout”);
}
else {
alert(t);
}
}
});
}
A few things are important and worth mentioning. In the “data” parameter I get the value of __REQUESTDIGEST and pass it in the POST request. (NOTE: you may want to improve the $(“#__RE..”) selector to get only input/hidden elements and be better performing). This will allow SPUtility.ValidateFormDigest() to pass successfully. If ever in doubt, open the request with Fiddler and validate the contents, you should see something like this:
The other important point is the contentType parameter. For me this did not work when set to “text/plain; charset=utf8”. I didn’t have enough time to figure out why, but “application/x-www-form-urlencoded” succeeded successfully.
Hope this helps!