WebParts fail to import for readers? here is a possible fix

One of our partners faced a problem that I think we will eventually see occurring frequently with external customers, so I thought to document the problem’s symptoms and a possible fix..

Problem Context:

1. You have a v2 WebPart (didn’t try it with v3 but it’s likely to repro as well), that you deployed to a server.

2. You (or some developer who uses your WebPart), creates a feature, with an elements file that tries to deploy that WebPart into a page, something like this:

    <Elements xmlns="<a href="https://schemas.microsoft.com/sharepoint/"">https://schemas.microsoft.com/sharepoint/"</a>>
   

    <Module Name="MyModule" Url="Shared Documents" >
   

     <File Url="Test.aspx" Type="GhostableInLibrary" >
   

      <AllUsersWebPart WebPartZoneID="Header" WebPartOrder="1">
   

       <![CDATA[
   

        <?xml version="1.0" encoding="utf-8"?>
   

         <WebPart xmlns:xsd="<a href="https://www.w3.org/2001/XMLSchema"">https://www.w3.org/2001/XMLSchema"</a> xmlns:xsi="<a href="https://www.w3.org/2001/XMLSchema-instance"">https://www.w3.org/2001/XMLSchema-instance"</a> xmlns="<a href="https://schemas.microsoft.com/WebPart/v2"">https://schemas.microsoft.com/WebPart/v2"</a>>
   

         <Title>A Test</Title>
   

         <FrameType>Default</FrameType>
   

         <Description />
   

         <IsIncluded>true</IsIncluded>
   

         <ZoneID>Header</ZoneID>
   

         <PartOrder>0</PartOrder>
   

         <FrameState>Normal</FrameState>
   

         <Height>222px</Height>
   

         <Width></Width>
   

         <AllowRemove>false</AllowRemove>
   

         <AllowZoneChange>false</AllowZoneChange>
   

         <AllowMinimize>false</AllowMinimize>
   

         <IsVisible>true</IsVisible>
   

         <DetailLink />
   

         <HelpLink />
   

         <Dir>Default</Dir>
   

         <PartImageSmall />
   

         <MissingAssembly />
   

         <PartImageLarge />
   

         <IsIncludedFilter />
   

         <ID>g_A4D135E1_0834_4b88_AA94_E7EC5BA80E93</ID>
   

         <Assembly>MyWebPartAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</Assembly>
   

         <TypeName>MyWebParts.WebPart1</TypeName>
   

         </WebPart>            ]]>
   

      </AllUsersWebPart>
   

     </File>
   

    </Module>
   

   </Elements>
   

3. Login as admin, enable the feature.. do NOT browse to Shared Documents\test.aspx.

4. Login as reader/visitor and try to browse to that page, you will be greeted with an ErrorWebPart saying:

   Error Web Part Error: 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.

5. If, at this point, you logged in as Admin, the WebPart will render just fine and any reader logs in from now on will render just fine as well

The problem:

Well, it’s hard to call it a problem, it’s a design decision we took. Sharepoint at that first page visit, will do the WebPart import into the page, and as it’s a reader who tries to do the import, it fails.

The solution:

The failure (as the text tells) is because the logged in user doesn’t have AddAndCustomizePages permission, this error pops up in different places but the reason for that specific one is because MyWebPart1 is not marked as SafeAgainstScript=True (I’ve a post about it here). You don’t want to mark just any WebPart as SafeAgainstScript=True because that can expose you, the site and your users to danger. At this point you have 3 options:

1. If you know for sure that non of your WebPart properties accepts strings from users (or that you do proper encoding/stripping to any script you might get), then go ahead and mark the WebPart as SafeAgainstScript=True in the <SafeControls> entry.
2. If you are unsure, then your best bet is to mark it as SafeAgainstScript=True and put [RequiresDesignerPermissions] attribute on all properties of your WebPart. This will allow readers to import the WebPart but not to change any.
3. Just let your users be aware of this scenario .

That’s it for now… stay tuned!

Comments

• Anonymous
  November 08, 2012
  I'm running into the same issue.  Have you found any other workarounds, other than for an admin. to hit the page first?  E-mail me at:  edward_mueller@dell.com.  Thanks.