Erreur lors de la mise à jour de SPPersistedObject à partir du composant WebPart

Question

J'ai écrit deux fonctionnalités dans SharePoint 2007. L'une est définie au niveau du site et elle ajoute un composant WebPart à la collection de sites où elle est activée. Cet ensemble de fonctionnalités est déployé sous le répertoire 'bin'. Second est la portée de la batterie, qui est mon SPPersistedObject personnalisé et est déployée dans l'Administration centrale. L'assembly est ajouté à GAC.

De la partie Web, j'ai besoin de mettre à jour mon objet personnalisé. Cela fonctionne bien dans la plupart des cas. Mais sur certains serveurs qui suivent les moins administration de http://technet.microsoft.com/en-us/library/cc263445.aspx 'comptes de domaine de privilège que je reçois l'erreur ci-dessous

System.Security.SecurityException: Accès refusé. au Microsoft.SharePoint.Administration.SPPersistedObject.Update() à MyWebPart. <> c__DisplayClass1.b__0() at Microsoft.SharePoint.SPSecurity.CodeToRunElevatedWrapper (objet état) à Microsoft.SharePoint.SPSecurity. <> c__DisplayClass4.b__2() à Microsoft.SharePoint.Utilities.SecurityContext.RunAsProcess (CodeToRunElevated SecureCode) à Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges (WaitCallback SecureCode, objet param) à Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges (CodeToRunElevated SecureCode) à MyWebPart.RenderWebPart (HtmlTextWriter écrivain) la zone de l'assemblée qui a échoué était : MonOrdinateur

Ai-je besoin de définir toutes les autorisations ou les politiques CAS pour prévenir cette erreur? Ci-dessous figure mon ensemble de règles CAS en vigueur pour l'assemblage de composants WebPart. Dois-je faire des changements ici?

<CodeAccessSecurity> 
    <PolicyItem> 
     <PermissionSet class="NamedPermissionSet" version="1" Name="MyPermission" Description="Permission set for my solution"> 
     <IPermission class="System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Level="Medium" /> 
     <IPermission class="System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> 
     <IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> 
     <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="AllFlags" /> 
     <IPermission class="Microsoft.SharePoint.Security.WebPartPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" Connections="true" /> 
     <IPermission class="Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" version="1" ObjectModel="true" UnsafeSaveOnGet="true" Impersonate="true"/> 
     <IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true"> 
      <ConnectAccess> 
      <URI uri="$OriginHost$"/> 
      <URI uri="http://.*\.xyz\.com/.*"/> 
      </ConnectAccess> 
     </IPermission> 
     </PermissionSet> 
     <Assemblies> 
     <Assembly Name="MyWebPart" Version="1.0.0.0" PublicKeyBlob="0024000004800000940000000602000000240000525341310004000001000100df0e85cb8c660241cd3225eb653a590b91303ddbd37f8f1e661d2dffb840a258b899d6bacbbc55d03768d5ea0260ee4c8341fd447d7200abdb74b837733c3f756833e169cae803aef808530dd3ddad953a49492faee3eeba6f0dba66b0d66f1f9ca5266c69dcb799ed364db5e9e6ebcd4e81fb27365de962cbe6e7e7fba300dc"/> 
     </Assemblies> 
    </PolicyItem> 
    </CodeAccessSecurity> 

Veuillez nous consulter.

Cordialement, Jagannath

Answer 1

Jagannath,

Le problème que vous rencontrez est dû au fait que le magasin de support pour les données de SPPersistedObject types dérivée de est la base de données de configuration de batterie de serveurs SharePoint. Dans une installation avec les privilèges minimum, le seul compte qui a autre chose que l'accès en lecture à cette base de données est le compte de service de batterie (service de minuterie). Même l'élévation des privilèges dans votre code va seulement «élever» votre contexte de sécurité à celui du compte du pool d'applications sous lequel le site est exécuté dans IIS.

J'ai rencontré la situation que vous êtes avant, et je suis seulement au courant de deux façons de contourner:

1. Trouver un moyen pour exécuter votre code d'application dans le cadre de la compte de service agricole. Cela se traduit normalement par l'exécution du code en tant que travail de minuteur personnalisé.

2. Ajustez les autorisations de la base de données de configuration de batterie de serveurs pour accorder au compte du pool d'applications (supposé lors de l'exécution d'un bloc de sécurité élevé) un accès en écriture.

de ces deux options, seule la première option reste fidèle au principe « moins de privilèges » d'exécution ... mais il n'entraîne re-architecturer votre code.

En général, j'ai eu de la chance de créer un travail de minuterie personnalisé "de balayage" qui est créé et programmé pour s'exécuter au moment de l'activation de la fonction. Ce travail vérifie ensuite la collection de sites (en balayant généralement une application Web entière) pour voir si les propriétés doivent être conservées, mises à jour, etc. Si des mises à jour sont nécessaires, elles sont effectuées par le travail du minuteur. niveau.

Un exemple de ce que je décris apparaît dans une fonction que j'ai créée sur CodePlex (http://blobcachefarmflush.codeplex.com/SourceControl/changeset/view/53851#797787). J'avais besoin de mettre à jour le sac Propriétés sur une instance SPWebApplication et la seule façon de le faire était dans le contexte d'un travail du minuteur. Lorsqu'un utilisateur effectue des modifications à partir de l'interface utilisateur, un indicateur est défini dans la collection de propriétés de RootWeb de la collection de sites. Le travail du minuteur parcourt la collection de sites et, lorsqu'il voit un tel indicateur, il prend en charge les modifications nécessaires dans le contexte de sécurité approprié.

J'espère que cela aide!

Answer 2

class MySett : SPPersistedObject 
{ 
    //... 
    protected override bool HasAdditionalUpdateAccess() { return true; } 
}