So this was a fun error. Took most of a day to figure out, well, to find an answer. I found it on an MSDN Forum so I decided to share it here since It was on page 4 of a Google search. Very agravating. The error I was getting was
The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.
when I was trying to SPListItem.RoleAssignments.Add(SPRoleAssignment) after a SPlistItem.BreakRoleInheritance(false). My original post in the MSDN Forum is here, it has more code and explains the entire situation better.
So, from the MSDN Forum post, the solution is below.
Problem Description:
===============
When you call SPList.BreakRoleInheritance(false) from an HTTP GET request, although you have specified SPWeb.AllUnsafeUpdates=true, you will still be thrown an exception
Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb.
Cause:
=====
This is by design limitation of SPList.BreakRoleInheritance
BreakRoleInheritance does it work in two steps. First, it needs to revert its permission to have same permission settings as parent (this is a less expensive operation, and give the list a fresh start on its road to unique permission). Later it checks CopyRoleAssignments parameter. If it is false, it takes an extra step to clean up permission on the list. A side effect of step 1 is that it dirties some internal objects in SPWeb, and cause them to be recreated. Unfortunately, the re-creation of those internal objects cause SPWeb.AllowUnsafeUpdates to have a default value which is false. That is, SPWeb.AllowUnsafeUpdates is reset in middle of call to SPList.BreakRoleInheritance, therefore we got the exception.
Resolution:
========
There are two possible workarounds to the issue:
1. Call SPList.BreakRoleInheritance from a HTTP POST request. That is, we can first have a button on UI and have users to click. In response to users’ click, we call SPList.BreakRoleInheritance. There is a first HTTP GET request by which, SharePoint has a chance to embed some digest to validate requests on return (HTTP POST). Therefore, we no longer need to set SPWeb.AllowUnsafeUpdates=true. This is recommended approach from security perspective.
2. First call SPList.BreakRoleInheritance(true). Then, use custom code to clean up permission and create your own permission set for the list as needed. The sample code are:
SPWeb web = SPControl.GetContextWeb(this.Context);
SPListCollection lists = web.Lists;
//Guid docLibGuid = lists.Add("Doc Lib Sample 1", "Doc Lib Desc", SPListTemplateType.DocumentLibrary);
//SPList docLib = lists[docLibGuid];
SPList docLib = lists["Doc Lib Sample 1"];
//docLib.ParentWeb.AllowUnsafeUpdates = true;
docLib.BreakRoleInheritance(true); //Exception throw here when the parameters is "false"
web.AllowUnsafeUpdates = true;
SPRoleAssignmentCollection roleAssigns = docLib.RoleAssignments;
for (int i = roleAssigns.Count-1; i >= 0; i--)
{
roleAssigns.Remove(i);
}