Retornando um SPListItem em conjunto com RunWithElevatedPrivileges

Question

* *Esclarecimento.Aplicativo == Definição do Site.O acesso direto ao banco de dados está fora da janela ** Criei um aplicativo para o SharePoint que utiliza algumas novas abordagens para o acesso da lista de codificação.Estruturei as coisas de uma forma que me permite controlar a interação dos dados de maneira precisa.

Por exemplo, eu tenho uma classe chamada Post, que possui alguns metadados típicos como Título, Resumo, etc...

Inside Post é um método estático chamado NewPost que retorna um SPListItem pré-formatado para uso na criação de novos posts.

public static SPListItem NewPost(string Title,string Summary)
{
   Posts = CoreLists.Posts();
   var item = Posts.AddItem();
   var item["Alias"] = SPContext.Current.Web.CurrentUser.LoginName;
   return item;
}

Você notará que estou obtendo o SPList por meio de uma classe auxiliar chamada CoreLists

public static class CoreLists
{
   public static SPList Posts()
   {
      return SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Posts");
   }
}

Isso cria alguns métodos interessantes de limpeza de dados.O que estou descobrindo é que não consigo encontrar uma maneira decente de chamar esses métodos com SPSecurity.RunWithElevatedPrivileges

SPSecurity.RunWithElevatedPrivileges não pode funcionar com um bloco de retorno; portanto, quando tento criar um novo item de lista, ele sempre falha.

Estou fazendo isso porque estou ocultando minhas listas.Quero que as pessoas os acessem apenas por meio da UI que estou criando.Quero bloquear ainda mais o sistema contra hackers de URL, permitindo que apenas administradores criem itens e usar SecurityBits para bloquear a edição de itens apenas para os criadores de itens de lista.

Portanto, todos os itens da lista são criados por conta do sistema e possuem um campo chamado Alias ​​​​que me permite associar o item a um usuário.

Preciso repensar toda a minha camada de acesso a dados?A decisão de restringir o acesso à lista entra em conflito absoluto com o desejo de uma camada de acesso a dados mais limpa?

Answer 1

Você usa SPContext.Current.Web dentro de SPSecurity.RunWithElevatedPrivileges delegar?

Isso não vai funcionar.Conseguir coisas com SPContext fornece objetos que têm o contexto do usuário atualmente conectado, não o elevado.Isso significa que se você criar uma nova entrada de lista usando objetos provenientes SPContext, eles serão criados no contexto de segurança do usuário atualmente conectado, e não do usuário elevado que você acha que os está criando.

Se quiser criar entradas de lista usando sharepoint\system, você precisará abrir novos objetos SPSite/SPWeb dentro do delegado SPSecurity.RunWithElevatedPrivileges e trabalhar com eles.

Tente mudar isso:

   public static SPList Posts() 
   { 
      return SPContext.Current.Web.GetList(SPContext.Current.Web.ServerRelativeUrl + "/lists/Posts"); 
   } 

para isso:

   public static SPList Posts() 
   { 
        using( var s = new SPSite(SPContext.Current.Site.ID)
        {
            using( var w = SPSite.OpenWeb(SPContext.Current.Web.ID)
            {
                 var postsList = w.Lists.TryGetList("Posts"); 
                 if( postsList != null )
                      return postsList;
                 else
                    /* do proper error handling */
            }
        }
    }

Agora seu posts.AddItem() deve criar entradas de lista com o contexto elevado corretamente.

Leia mais sobre elevação de privilégios no MSDN:http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx

Answer 2

Não use RWEP.Você não precisa disso.

As listas ocultas não requerem codificação especial para serem acessadas.Se o usuário atual tiver permissões para a lista, basta acessar a lista oculta como faria com qualquer outra lista.

Se o usuário atual não tiver permissões para a lista e você desejar fazer proxy da atualização por meio de código, você deverá representar a conta do sistema.Além disso, você não deve passar um objeto através dos limites de segurança.Sugiro criar um objeto de transferência de dados que você passe para sua camada de dados.

Answer 3

Os pontos de Vedrans sobre UI/Segurança estão certos - se você está reescrevendo o sistema de segurança, você está trabalhando contra a corrente, por assim dizer. Mas você ainda pode querer aproveitar a segurança (e outros benefícios do SharePoint), então não é completamente mental para construir um aplicativo no SharePoint.

Para uma arquitetura mais baseada no SharePoint - use um site de publicação.Isso lhe dá:

1. a UI padrão do sharepoint para listas, etc.- esta é a visualização dos 'bastidores' do administrador.
2. biblioteca de páginas com página mestra/UI separada - esta é a interface do 'aplicativo'.

Padrão (todos os usuários autenticados) obtém acesso de visualizador ao site.Os usuários 'admin' obtêm permissões de contribuidor/explícitas para listas, qualquer que seja.

Os apostadores só podem acessar os dados do site por meio de web parts/códigos personalizados na interface do aplicativo.

Answer 4

Todo o seu conceito está errado.

Se você está desenvolvendo sua própria interface de usuário e segurança, por que está usando o SharePoint?Usar SQL é muito mais limpo.

Cada vez que você usa SPSecurity.RunWithElevatedPrivileges no código, a segurança do Sharepoint está comprometida porque você está permitindo que o usuário atual atue como SHAREPOINT\System e tenha acesso a tudo.

A propósito, você pode definir 'criador' ao executar em SPSecurity.RunWithElevatedPrivileges

//First store current user
SPUser currentUser = SPContext.Current.Web.CurrentUser;

SPSecurity.RunWithElevatedPrivileges(delegate 
{
    using (SPSite elevatedSite = new SPSite(SPContext.Current.Site.Url))
    using (SPWeb targetWeb = elevatedSite.OpenWeb(webUrl))
    {
       //Code to get your item or to add a new one

       // Replace 'System Account' with current user
       item["Author"] = currentUser;
       item["Editor"] = currentUser;
       item.SystemUpdate();
    }
});

ADIÇÃO:

Para evitar mais interpretações erradas:usando SQL, não quis dizer banco de dados SharePoint, mas algum outro banco de dados SQL diferente.Por que?Como você está usando UI personalizada, verificações de segurança personalizadas, sua lista está oculta (para que os usuários não possam usar os recursos do SP OOTB, como classificação, filtragem etc.), a pesquisa também não é uma opção -> realmente não vejo nenhuma vantagem em usar o SharePoint como armazenamento de dados.