Nicolas Humann

SPWeb.BreakRoleInheritance(false) dans une requête Http GET

Problème:

Lorsque vous appelez SPWeb.BreakRoleInheritance(false) à partir d'une demande HTTP GET, une exception est toujours levée bien que vous ayez spécifié SPWeb.AllUnsafeUpdates=true

Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb.

Cause:

Il s'agit d’une limitation « by design » de SPWeb.BreakRoleInheritance.

BreakRoleInheritance fonctionne en deux étapes.

Tout d'abord, il doit supprimer les permissions et copier les autorisations du site parent .

Ensuite, il vérifie le paramètre CopyRoleAssignments. Si la valeur est à false, il effectue une étape supplémentaire pour nettoyer les autorisations.

Malheureusement, il y a un effet de bord à l'étape 1, il “casse” certains objets internes de SPWeb et provoque à nouveau la création des autorisations. Or, la recréation de ces objets internes pousse SPWeb.AllowUnsafeUpdates à avoir une valeur par défaut, qui est la valeur false. En d'autres termes, SPWeb.AllowUnsafeUpdates est réinitialisé au milieu de l’appel à SPWeb.BreakRoleInheritance, il y a donc une exception!!

La solution:

Il existe deux solutions possibles à ce problème:

1. Vous faites appel à SPWeb.BreakRoleInheritance dans une requête HTTP POST. Il n’est donc plus nécessaire de faire un SPWeb.AllowUnsafeUpdates=true. C’est d’ailleurs recommandé d’un point de vue sécurité.
2. Vous voulez absolument faire appel à SPWeb.BreakRoleInheritance dans une requête HTTP GET. Il faut appeler SPWeb.BreakRoleInheritance avec le paramètre true.

Cette solution s'applique égualement pour SPList.BreakRoleInheritance.

SPWeb web = SPControl.GetContextWeb(this.Context);
web.AllowUnsafeUpdates = true;
//Attention, une exception est levée si le paramètre est à "false"
docLib.BreakRoleInheritance(true); 
SPRoleAssignmentCollection roles = docLib.RoleAssignments;
for (int i = roles.Count-1; i >= 0; i--)
{    
roles.Remove(i);
}