Renvoyer un SPListItem en conjonction avec RunWithElevatedPrivileges

Question

* *Clarification.Application == Définition du site.L'accès direct à la base de données est par la fenêtre ** J'ai créé une application pour SharePoint qui utilise de nouvelles approches de l'accès à la liste de codage.J'ai structuré les choses d'une manière qui me permet de contrôler l'interaction des données de manière précise.

Par exemple, j'ai une classe appelée Post, qui contient des métadonnées typiques comme le titre, le résumé, etc...

Inside Post est une méthode statique appelée NewPost qui renvoie un SPListItem préformaté à utiliser lors de la création de nouvelles publications.

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

Vous remarquerez que j'obtiens la SPList via une classe d'assistance appelée CoreLists.

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

Cela donne lieu à de belles méthodes de données propres.Ce à quoi je me heurte, c'est que je ne trouve pas de moyen décent d'appeler ces méthodes avec SPSecurity.RunWithElevatedPrivileges

SPSecurity.RunWithElevatedPrivileges ne peut pas fonctionner avec un bloc de retour, donc lorsque j'essaie de créer un nouvel élément de liste, cela échoue à chaque fois.

Je fais cela parce que je cache mes listes.Je veux que les gens y accèdent uniquement via l'interface utilisateur que je crée.Je souhaite verrouiller davantage le système contre le piratage d'URL en autorisant uniquement les administrateurs à créer des éléments et en utilisant SecurityBits pour verrouiller la modification des éléments uniquement aux créateurs d'éléments de liste.

Par conséquent, tous les éléments de liste sont créés par le compte système, puis ils comportent un champ appelé Alias ​​qui me permet de faire correspondre l'élément à un utilisateur.

Dois-je repenser l’ensemble de ma couche d’accès aux données ?La décision de restreindre l’accès aux listes est-elle absolument en conflit avec le désir d’une couche d’accès aux données plus propre ?

Answer 1

Tu utilises SPContext.Current.Web à l'intérieur de SPSecurity.RunWithElevatedPrivileges déléguer?

Cela ne fonctionnera pas.Obtenir des trucs avec SPContext vous donne des objets qui ont le contexte du utilisateur actuellement connecté, pas celui élevé.Cela signifie que si vous créez une nouvelle entrée de liste en utilisant des objets provenant de SPContext, ils seront créés dans le contexte de sécurité de l'utilisateur actuellement connecté, et non de l'utilisateur élevé qui, selon vous, les crée.

Si vous souhaitez créer des entrées de liste à l'aide de sharepoint\system, vous devez ouvrir de nouveaux objets SPSite/SPWeb dans le délégué SPSecurity.RunWithElevatedPrivileges et travailler avec ceux-ci à la place.

Essayez de changer ceci :

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

pour ça:

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

Maintenant, votre posts.AddItem() devrait créer des entrées de liste avec le contexte correctement élevé.

En savoir plus sur l’élévation de privilèges sur MSDN :http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx

Answer 2

n'utilisez pas RWEP.Tu n'en a pas besoin.

Les listes cachées ne nécessitent pas de codage spécial pour accéder.Si l'utilisateur actuel a des autorisations sur la liste, il suffit d'accéder à la liste cachée comme vous le feriez une autre liste.

Si l'utilisateur actuel n'a pas d'autorisations à la liste et que vous souhaitez proxy la mise à jour via le code, vous devez imiter le compte système.De plus, vous ne devez pas passer un objet entre les limites de la sécurité.Je suggère de créer un objet de transfert de données que vous transmettez dans votre couche de données.

Answer 3

Les points VEDRANS RE UI / Security sont tout à fait corrects - si vous réécrivez le système de sécurité, vous travaillez contre le grain tel qu'il était. mais Vous voudrez peut-être toujours tirer parti de la sécurité (et d'autres prestations SharePoint), donc ce n'est pas complètement mental pour créer une application sur SharePoint.

Pour une architecture davantage basée sur SharePoint - utilisez un site de publication.Cela vous donne:

1. l'interface utilisateur SharePoint standard pour les listes, etc. - Ceci est la vue Admin 'Backstage'.
2. Bibliothèque de pages avec une page principale / interface utilisateur distincte - Il s'agit de l'interface "Application".

   Par défaut (tous les utilisateurs authentifiés) Obtenez l'accès au visualiseur sur le site.Les utilisateurs de «administrateur» obtiennent des autorisations de contributeur / explicites aux listes, peu importe.

   Les parieurs ne peuvent accéder que les données de sites via des parties Web / code Web personnalisées dans l'interface d'application.

Answer 4

Votre concept entier est faux.

Si vous développez votre propre assurance-emploi et votre propre sécurité, pourquoi utilisez-vous SharePoint?En utilisant SQL est beaucoup plus propre.

Chaque fois que vous utilisez SPSecurity.RunWithElevatedPrivileges dans le code SharePoint Security est compromis car vous permettez à l'utilisateur actuel d'agir en tant que SharePoint \ System et d'avoir accès à tout.

BTW Vous pouvez définir "Créateur" lors de l'exécution sous 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();
    }
});

Addition:

Pour éviter toute mauvaise interprétation erronée: en utilisant SQL, je ne voulais pas avoir signé de base de données SharePoint, mais une autre base de données SQL différente.Pourquoi?Étant donné que vous utilisez UI personnalisé, des contrôles de sécurité personnalisés, votre liste est masquée (les utilisateurs ne peuvent pas utiliser SP Ootb fonctionnalités telles que le tri, le filtrage, etc.), la recherche n'est pas une option -> Je ne vois vraiment aucun avantage d'utiliser SharePointcomme stockage de données.