Utilizando o SPSecurity.RunWithElevatedPrivileges

Imagine o seguinte cenário: os usuários do site SharePoint utilizam uma web part customizada para trabalhar com os dados de uma lista, mas se eles tentarem alterar os dados pela interface do SharePoint, ao invés dessa web part, o SharePoint não pode deixar eles fazerem essas alterações. Uma forma simples de resolver isso é tirar o acesso de colaboração desta lista para todos os usuários e fazer toda a interação da lista pela web part. Mas se o usuário não tem acesso, a web part não irá dar mensagem de acesso negado?

Outro cenário: a lista possui um event receiver que altera as permissões do item e, se necessário, cria um grupo de usuários no site SharePoint. Dificilmente os usuários comuns terão acesso no site para a criação de grupos.

Neste post vamos discutir esses pontos e ver como resolvê-los.

Os cenários acima são diferentes, mas caem no mesmo ponto: os componentes como web parts, event receiver e alguns outros são executados com a identidade do usuário logado no site, ou seja, se o usuário atual não tem permissão de editar um item de lista ou criar um grupo de usuários, essa permissão será respeitada.

Mas se eu precisar realmente fazer isso, não tem como? Tem sim, para isso temos o método RunWithElevatedPrivileges que permite que o código seja executado com privilégios de controle total dentro do site, o que resolveria os problemas apresentados nos cenários anteriores.

Isso não seria uma falta de segurança, permitir que o usuário tenha essa permissão total via componentes de desenvolvimento? Depende da governança existente, se qualquer um poder subir componente é sim, senão não. Por que é a melhor forma de resolver este problema.

A sintaxe básica para utilizar o SPSecurity.RunWithElevatedPrivileges está descrita na listagem 01. Repare que é necessário criar um delegate e colocar todo o código que será executado com privilégio elevado dentro dele, o que pode ser chamada de métodos.

SPSecurity.RunWithElevatedPrivileges(delegate ()
{
   // implementation details ommited
}

Listagem 01: Forma de execução do RunWithElevatedPrivileges

 

É comum utilizar os objetos SPSite e SPWeb do contexto, através do SPContext, mas neste cenário não se deve utilizar o contexto. Isso porque o contexto está com a identidade do usuário logado no site SharePoint, mas não é isso que queremos, sendo assim é necessário criar um novos objetos SPSite e SPWeb, como mostra a listagem 02, que está pegando o ID do site e lista a partir de um objeto SPListItem.

SPSecurity.RunWithElevatedPrivileges(delegate ()
{
   using (SPSite site = new SPSite(listItem.Web.Site.ID))
   {
      using (SPWeb web = site.OpenWeb(listItem.Web.ID))
      {
         // implementation details omitted
      }
   }
}

Listagem 02: Criando objetos SPSite e SPWeb

 

Com o uso do SPSecurity.RunWithElevatedPrivileges conseguimos executar código que necessita de permissão elevada dentro do conteúdo do SharePoint, sem que o usuário logado tenha os níveis de permissão necessários.

 

Referências:

About these ads

2 Respostas to “Utilizando o SPSecurity.RunWithElevatedPrivileges”


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 41 outros seguidores

%d blogueiros gostam disto: