La restituzione di un a splistitem in collaborazione con RunWithElevatedPrivileges

Question

* *Il chiarimento.Applicazione == Definizione Del Sito.L'accesso diretto al Database è fuori dalla finestra ** Ho creato un'applicazione per SharePoint che utilizza alcuni nuovi approcci per la codifica Elenco di Accesso.Ho strutturato le cose in un modo che mi permette di controllare l'interazione dei dati in modo preciso.

Per esempio, ho una classe chiamata Post, che ha alcune tipiche metadati come Titolo, Sintesi, ecc...

All'interno del Post è un metodo statico, chiamato NewPost che restituisce un pre-formattato a splistitem per l'uso nella creazione di nuovi posti.

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;
}

Si noterà che ho sono sempre SPList attraverso una classe di supporto chiamato CoreLists

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

Questo rende per qualche bella pulita metodi di dati.Quello che sto correndo in a, è che non riesco a trovare un modo decente per chiamare questi metodi con SPSecurity.RunWithElevatedPrivileges

SPSecurity.RunWithElevatedPrivileges non può funzionare con un ritorno di blocco, in modo che quando cerco di creare una nuova voce di elenco, non riesce ogni volta.

Sto facendo questo perché sto facendo il mio liste di nascosto.Io voglio che la gente solo l'accesso tramite l'interfaccia sto creando.Voglio ulteriormente bloccare il sistema da URL, hacking, consentendo solo agli amministratori di creare elementi e utilizzare SecurityBits per bloccare voce modifica solo per i creatori di elementi di una lista.

Pertanto, tutte le Voci dell'Elenco sono creato con l'Account di Sistema, e quindi hanno un campo chiamato Alias che mi permette di abbinare la voce di un utente.

Ho bisogno di ripensare tutto il mio Livello di Accesso ai Dati?La decisione di limitare l'Accesso Elenco conflitto assolutamente con il desiderio per un pulitore di Livello di Accesso ai Dati?

Answer 1

Si utilizza SPContext.Current.Web all'interno del SPSecurity.RunWithElevatedPrivileges delegato?

Che non è andare a lavorare.Fare cose con SPContext ti da oggetti che è il contesto del utente attualmente connesso, non la elevati di uno.Che significa che se si crea una nuova voce di elenco l'uso di oggetti che viene da SPContext, essi saranno creati nel contesto di protezione dell'utente attualmente connesso, e non l'utente elevati si pensa è la creazione di loro.

Se si desidera creare un elenco di voci utilizzando sharepoint\sistema, è necessario per aprire nuove SPSite/SPWeb oggetti all'interno di SPSecurity.RunWithElevatedPrivileges delegato e del lavoro con quelli invece.

Provare a cambiare questa:

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

per questo:

   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 */
            }
        }
    }

Ora i vostri messaggi.AddItem() dovrebbe creare un elenco di voci con la corretta contesto con privilegi elevati.

Leggi di più su l'elevazione di privilegi su MSDN:http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx

Answer 2

Non utilizzare RWEP.Non hai bisogno di esso.

Nascosto liste non necessitano di una particolare codifica per accedere.Se l'utente corrente non dispone di autorizzazioni per l'elenco, poi basta accedere all'elenco nascosto come si farebbe con qualsiasi altro elenco.

Se l'utente corrente non dispone di autorizzazioni per l'elenco, e si desidera proxy l'aggiornamento via codice, deve rappresentare l'Account di Sistema.Inoltre, non si dovrebbe mai passare un oggetto di fronte limiti di sicurezza.Suggerisco di creare oggetto di trasferimento dati che si passa il livello dati.

Answer 3

Vedrans punti re UI/di Sicurezza sono abbastanza di destra - se stai riscrivendo il sistema di sicurezza, si sta lavorando contro il grano come erano. Ma ci si può comunque sfruttare la sicurezza (e di altri SharePoint benefici), quindi non completamente mentale per creare un'app di SharePoint.

Per di più basate su SharePoint architettura - utilizzare un sito di pubblicazione.Questo ti dà:

1. la UI standard di sharepoint per le liste etc.- questo è l'admin 'backstage' vista.
2. raccolta di pagine con separata pagina master/UI - questa è l'applicazione' interfaccia.

Di Default (tutti gli utenti autenticati) ottenere il visualizzatore di accesso al sito.'admin' agli utenti di ottenere contributer/autorizzazioni esplicite, liste e quant'altro.

I giocatori possono accedere solo ai dati del sito attraverso la web part personalizzate/codice nell'interfaccia dell'applicazione.

Answer 4

Il tuo è un concetto sbagliato.

Se si sta sviluppando la propria interfaccia utente e la sicurezza, perché si sta utilizzando SharePoint?Utilizzo di SQL è molto più pulito.

Ogni volta che si utilizza SPSecurity.RunWithElevatedPrivileges nel codice di protezione di Sharepoint è compromessa poiché si consente corrente utente di agire come SHAREPOINT\Sistema e avere accesso a tutto.

Btw si può impostare il 'creatore' durante l'esecuzione in 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();
    }
});

AGGIUNTA:

Per evitare ulteriori fraintendimenti:utilizzando SQL non ho inteso database di SharePoint, ma altri database SQL.Perché?Dal momento che si sta utilizzando un'interfaccia utente personalizzata, personalizzato controlli di sicurezza, il tuo elenco sono nascosti (in modo che gli utenti non possono utilizzare SP OOTB caratteristiche come l'ordinamento, filtro, etc.), la ricerca, inoltre, non è un'opzione -> io davvero non vedo nessun vantaggio dell'utilizzo di SharePoint come l'archiviazione dei dati.