Non è possibile consentire ai visitatori di aggiungere il WebPart utente solo su alcune pagine

Question

In un portale Intranet aziendale, voglio consentire a qualsiasi visitatore (qualsiasi utente autenticato) di personalizzare alcune pagine con le parti del web utente.

Voglio limitare questa personalizzazione solo su alcune pagine.

Ormai ho creato un nuovo livello di autorizzazione " Personalizza utente WebParts ", che definisce queste autorizzazioni:

.
• Aggiungi e personalizza le pagine
• Aggiungi / rimuovi i web componenti personali
• Aggiorna i web componenti personali

  Questo è il set più piccolo di autorizzazioni che trovo per consentire l'aggiunta di utenti WebParts.

  Nel mio portale, ho un gruppo " del mio portale ".

  Se applico a questo gruppo il livello di autorizzazione personalizzato (mantenendo il livello di autorizzazione di lettura OOB) al livello Web , posso aggiungere parti web utente sulle pagine.

  Tuttavia, se applico questo livello di autorizzazione alla libreria pagina livello o pagina specifica livello (interruzione delle autorizzazioni di rottura), non posso aggiungere webpart utente. .

  È possibile applicare queste autorizzazioni solo su pagine specifiche?

  Si prega di notare che I può rimuovi o aggiorna o aggiorna i WebParts. È solo aggiunta di WebPart che è limitato.

  FYI, i WebParts sono effettivamente aggiunti tramite codice, da un "gestore" personalizzato "WebPart.

  Soprattutto, questo codice sta lanciando l'eccezione:

  var mgr = web.GetLimitedWebPartManager(file.ServerRelativeUrl, System.Web.UI.WebControls.WebParts.PersonalizationScope.User);
  var wpFile = web.GetCatalog(SPListTemplateType.WebPartCatalog).RootFolder.Files["somewebpart.webpart"];
  System.Web.UI.WebControls.WebParts.WebPart newWebPart;
  using (var raw = wpFile.OpenBinaryStream())
  {
      using (var xr = XmlReader.Create(raw))
      {
          string error;
          newWebPart = mgr.ImportWebPart(xr, out error); 
      }
  }
  

  .

  Il metodo ImportWebPart sta lanciando un'eccezione oscura:

  Microsoft.SharePoint.ApplicationRuntime.SafeControls+UnsafeControlException: A Web Part or Web Form Control on this Page cannot be displayed or imported. You don't have Add and Customize Pages permissions required to perform this action
     à Microsoft.SharePoint.WebPartPages.WebPartImporter.CreateWebPart(Boolean clearConnections)
     à Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager manager, XmlReader reader, Boolean clearConnections, Uri webPartPageUri, SPWeb spWeb)
     à Microsoft.SharePoint.WebPartPages.WebPartImporter.Import(SPWebPartManager manager, XmlReader reader, Boolean clearConnections, SPWeb spWeb)
     à Microsoft.SharePoint.WebPartPages.SPWebPartManager.ImportWebPart(XmlReader reader, String& errorMessage)
     à Microsoft.SharePoint.WebPartPages.SPLimitedWebPartManager.ImportWebPart(XmlReader reader, String& errorMessage)
     à x.y.z.ImportWebPart(SPLimitedWebPartManager mgr, SPFile wpFile)
  

  .

  Nei registri ULS, vedo solo questo:

  .

  Errore durante l'importazione di WebPart. Assemblaggio Microsoft.SharePoint, versione= 14.0.0.0, Cultura= Neutro, PublicKeyToken= 71E9BCE111E9429C, typeName. Microsoft.SharePoint.WebPartPages.ContententeditorWebPart

  che è abbastanza inquietante.

  [modifica] con riflettore, ho trovato nel metodo WebPartImporter.CreateWebPart questa verifica:

       if ((!this._spWeb.AllowContributorsToEditScriptableParts && !this._spWeb.DoesUserHavePermissions(SPBasePermissions.EmptyMask | SPBasePermissions.AddAndCustomizePages)) && !this._spWeb.SafeControls.SafeAgainstScript(this._type, out unsafeErrorMessage))
          {
              throw new SafeControls.UnsafeControlException(SafeControls.UnsafeControlException.MakeGenericUnsafeExceptionMessage(unsafeErrorMessage));
          }
  

  .

  In realtà, il codice da aggiungere un WebPart controlla l'autorizzazione sull'oggetto SPWeb.

  Dovrei concludere che il mio scenario non è supportato? : (

Answer 1

After some experiments, here is seems-to-work solution :

var web = SPContext.Current.Web;

var mgr = web.GetLimitedWebPartManager(file.ServerRelativeUrl, System.Web.UI.WebControls.WebParts.PersonalizationScope.User);


var wpFile = web.GetCatalog(SPListTemplateType.WebPartCatalog).RootFolder.Files["somewebpart.webpart"];



/* Elevated the process just for importing the webpart */
var elevatedWeb = GetElevatedWeb(web); // Get an elevated Web object, that points on the same web
var elevatedMgr = elevatedWeb.GetLimitedWebPartManager(file.ServerRelativeUrl, System.Web.UI.WebControls.WebParts.PersonalizationScope.User);
System.Web.UI.WebControls.WebParts.WebPart newWebPart;
using (var raw = wpFile.OpenBinaryStream())
{
    using (var xr = XmlReader.Create(raw))
    {
        string error;
        newWebPart = elevatedMgr.ImportWebPart(xr, out error); 
    }
}


/* Import the webpart, created in the elevated context, but into the current user's context. */
mgr.AddWebPart(newWebPart, "Left", 0);

Basically, the idea was to import the webpart under an elevated context, but add the imported web part in the actual current context.

It seems to work, but I'm not very fan o such hacking mechanism.

Answer 2

You want to allow any visitor (any authenticated user) to customize some pages with user web parts...Right?

How we do this where I work, we created a group that includes the accounts of all authenticated users. We can apply this permission group at any level, document through an entire site collection.

Hope this helps you out in some way...

Answer 3

In reviewing the method you find with reflector it does appear that it requires the web level permissions. You might want to consider executing the block with elevated permissions which should get you around the need for giving web level permissions. (Assuming this is a farm solution) If you go that route you might consider adding some extra logic checking in your custom manager web part to make sure the elevated privileges are not being used/invoked incorrectly.