Ho già parlato di come sia possibile modificare i diritti d’accesso ad ogni singolo item e di come sia possibile fare eseguire del codice con diritti di accesso più elevati di quelli che normalmente avrebbe l’utente connesso sugli oggetti interessati.
Se abbiamo la necessità, tramite una WebPart di modificare i diritti di accesso ad un item (presupponendo che il nostro utente non abbia l’autorizzazione a farlo) e proviamo a mettere insieme le due cose il codice potrebbe assomigliare a questo:
|
SPSite site = SPControl.GetContextWeb(this.Context).Site;
SPWeb web = SPControl.GetContextWeb(this.Context);
SPUser curUser = web.AllUsers[System.Security.Principal.WindowsIdentity.GetCurrent().Name];
SPSecurity.RunWithElevatedPrivileges(delegate()
{
using (SPSite elevatedSite = new SPSite(site.ID))
{
using (SPWeb elevatedWeb = elevatedSite.OpenWeb(web.ID))
{
if (elevatedWeb != null)
{
elevatedSite.AllowUnsafeUpdates = true;
elevatedWeb.AllowUnsafeUpdates = true;
SPListItem item = elevatedWeb.GetListItem("http://sito/docs/item");
// Verifica la permission inheritance, e se necessario la interrompe
if (!item.HasUniqueRoleAssignments)
item.BreakRoleInheritance(true);
for (int idx = item.RoleAssignments.Count – 1; idx >= 0; idx--)
{
item.RoleAssignments.Remove(item.RoleAssignments[idx].Member);
}
}
}
}
});
|
Un po’ a sorpresa il risultato sarebbe quello di produrre un’eccezione del tipo “the security validation for this page is invalid. Click Back in your web browser, refresh the page, and try your operation again”.
Non so bene se si tratti di un bug o di un comportamento voluto, ma tutto dipende dal fatto che il metodo BreakRoleInheritance effettua un reset del flag AllowUnsafeUpdates che assume nuovamente il valore false e ci impedisce quindi di effettuare altre modifiche ai permessi del nostro item.
Per far funzionare il codice è quindi necessario impostare di nuovo il flag AllowUnsafeUpdates dopo la chiamata al metodo BreakRoleInheritance:
|
// Verifica la permission inheritance, e se necessario la interrompe
if (!item.HasUniqueRoleAssignments)
{
item.BreakRoleInheritance(true);
elevatedWeb.AllowUnsafeUpdates = true;
}
|
La soluzione del problema è abbastanza semplice, tuttavia il comportamento del metodo BreakRoleInheritance mi sembra molto strano … io penso si tratti di un bug; chi non è d’accordo alzi la mano!
Technorati Tags: SharePoint