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:
- 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é.
- 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);
}
