Cliff Green's Blog : Web Parts

SharePoint Web Part Embedded Resource Permissions

green.cliff — Mon, 27 Oct 2008 17:45:46 GMT

It is a normal expectation for companies to embed resources like javascript, CSS and other resources in an assembly. Web Parts are no exceptions. For those of you that deploy everything to the GAC, you can disregard the remainder of this post. The rest of you, bear with me. If we are not deploying to the GAC we are typically deploying to the bin. The bin directory in SharePoint has the following permissions by default; full control for SYSTEM, Administrators and WSS_ADMIN_WPG groups, and read-only access for WSS_WPG group. This is not sufficient for embedded resources to be loaded by accounts that don't exists in one of these groups. If you run an assembly with embedded resources with anything other than an account that is in one of these groups you will get the following error:

Exception raised when trying to access embedded resources:
System.UnauthorizedAccessException: Access to the path 'C:\inetpub\wwwroot\wss\VirtualDirectories\80\bin\SampleWP.DLL' is denied. 
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) 
at System.IO.File.GetLastWriteTimeUtc(String path) at System.IO.File.GetLastWriteTime(String path) 
at System.Web.Handlers.AssemblyResourceLoader.GetAssemblyInfoWithAssertInternal(Assembly assembly) 
at System.Web.Handlers.AssemblyResourceLoader.GetAssemblyInfo(Assembly assembly) 
at System.Web.Handlers.AssemblyResourceLoader.GetWebResourceUrlInternal(Assembly assembly, String resourceName, Boolean htmlEncoded) 
at System.Web.Handlers.AssemblyResourceLoader.GetWebResourceUrl(Type type, String resourceName, Boolean htmlEncoded) 
at System.Web.UI.ClientScriptManager.GetWebResourceUrl(Page owner, Type type, String resourceName, Boolean htmlEncoded) 
at System.Web.UI.ClientScriptManager.RegisterClientScriptResource(Type type, String resourceName) 
at TestWebPart.ResourcePermissionTest.OnPreRender(EventArgs e)

The assembly doesn't have permission to access the bin directory. If you don't get this error do an IIS reset and then access the web part as a user that isn't in one of these groups. The difficult part of figuring this out was that if a user with permissions to write to the directory first accesses the web part it will render properly, not only for that user, but any user thereafter. This will happen until the cache is exhausted. So even during the debugging process I was wondering what the heck I just saw a couple of times.

On the surface the easy solution is to change the permissions and set 'everyone' to have read / write access and move on. What you will notice is that SharePoint will reset these permissions back to the standard after certain events. One of those events is deploying a solution. If you watch the directory you will notice that the bin permissions are recreated when this happens. The bin directory is actually deleted and recreated. So while the 'everyone' account will work temporarily, it isn't a long term solution.

What about CAS? Doesn't work. Contrary to some of the other posts out there about this this isn't a CAS issue. Granting the assembly 'Full' trust doesn't change the fact that an account that doesn't have access to the directory needs to write to it. While you can set the web.config and disable impersonation or create a CAS policy that doesn't impersonate, this isn't the best solution in cases where you need to impersonate the user. Windows Auth. comes to mind. It would allow you to take the non-impersonated account and add them to one of the built-in groups so the web part would function properly. This probably isn't an acceptable solution if you are an ISV or third party looking to distribute your web part to other parties. They may not be open to adding least privilege accounts to groups on their servers

One solution that does work is creating a folder in the web application directory and changing the web.config to add a probingPath in order to help the .NET runtime locate your assembly. By creating your own directory you control the permissions and they aren't reset by SharePoint. Your installation and setup are a little more trouble, but you have a solution that should work long term without sacrifices to the functionality of SharePoint or, most importantly, your web part.

Adding Web Parts to the Web Part Gallery Using the SharePoint Object Model

green.cliff — Fri, 18 Apr 2008 19:12:56 GMT

Since my first post was based on removing web parts from the web part gallery of a 'My Site' there have been questions about how to add the web parts back should circumstances require it. This is pretty straight-forward, but can get more interesting depending on how robust you want to make the end solution. The Web Part Gallery is a document library that holds a reference to a web part file, either a .dwp or .webpart file. This file is simply a metadata definition of the web part. To add a web part back in the gallery we can leverage the code shown below. This assumes that the web part assembly is installed and the safe control entries are made in the web.config file.

public static void IterateWebPartGallery(string siteCollectionUrl) {
    string filePath = @"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\PortalLayouts\DWP\owa.dwp";

    using ( SPSite site = new SPSite( siteCollectionUrl ) ) {
        using ( SPWeb web = site.OpenWeb() ) {

            SPList webPartGallery = web.GetCatalog( SPListTemplateType.WebPartCatalog );

            SPFolder folder = webPartGallery.RootFolder;
            if( folder != null ) {
                byte [] webPartFile = File.ReadAllBytes(filePath);
                FileInfo webPartFileInfo = new FileInfo(filePath);

                folder.Files.Add(webPartFileInfo.Name, webPartFile);
                folder.Update();
            }
        }
    }
}

The code gets a reference to the web part gallery in the target site collection by calling the SPWeb.GetCatalog() method. Once we have that reference we get a reference to the root folder of the gallery and call the folder.Files.Add() method to add the web part file. Calling folder.Update() persists this information to the database.

While this will simply add the file by parsing its contents it won't give us the fine grained control we may want for adding our web part to the gallery. If the file uses resources to define the title and description properties then those get loaded into the gallery "as is" using the method above. This makes our title $Resources:spscore,PeopleWebParts_OWA_Title_Text; and the description $Resources:spscore,PeopleWebParts_OWA_Desc_Text;.

This can be made a bit more robust by figuring out the title and description from the resource file and setting them in the gallery when the web part is loaded. The SPFolder.Files.Add() method has an overload that accepts a Hashtable reference where we can set additional properties for the web part. The resource values above indicate the resource file is the spscore resource file, spscore.en-US.resx for the en-US culture. Resource files in SharePoint are stored in the \12\Resources directory. I tried to load this file directly using the ResXResourceReader, but received an exception about a missing 'resheader' value in the file. Since .resx files are just Xml I decided to use an XPathNavigator and parse the values out that way. You could also dynamically parse the .webpart or .dwp file to figure out what the associated resx file the web part is referencing, but that is beyond the scope of this post. The final code snippet is shown below.

string filePath = @"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES\PortalLayouts\DWP\owa.dwp";
string resourceDirectory = @"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\Resources";

using ( SPSite site = new SPSite( siteCollectionUrl ) ) {
    using ( SPWeb web = site.OpenWeb() ) {

        SPList webPartGallery = web.GetCatalog( SPListTemplateType.WebPartCatalog );

        string title = "";
        string description = "";

        XPathDocument xml = new XPathDocument( File.Open( Path.Combine( resourceDirectory, "spscore.en-US.resx" ), FileMode.Open, FileAccess.Read ) );
        XPathNavigator navigator = xml.CreateNavigator();
        string xpathExpression = "/root/Data[@Name='{0}']/Value";
        XPathNavigator node = navigator.SelectSingleNode( string.Format( xpathExpression, "PeopleWebParts_OWA_Title_Text" ) );
        if ( node != null ) {
            title = node.Value;
        }
        node = navigator.SelectSingleNode( string.Format( xpathExpression, "PeopleWebParts_OWA_Desc_Text" ) );
        if ( node != null ) {
            description = node.Value;
        }


        SPFolder folder = webPartGallery.RootFolder;
        if ( folder != null ) {
            byte[] webPartFile = File.ReadAllBytes( filePath );
            FileInfo webPartFileInfo = new FileInfo( filePath );

            Hashtable properties = new Hashtable();
            properties.Add( "Title", title );
            properties.Add( "WebPartDescription", description );
            properties.Add( "Group", "Outlook Web Access" );


            folder.Files.Add( webPartFileInfo.Name, webPartFile, properties );
            folder.Update();
        }
    }
}

Create 'open tool pane' link in ASP.NET 2.0 Web Parts for SharePoint

green.cliff — Mon, 17 Mar 2008 03:22:14 GMT

I was recently asked how one could include the 'open tool pane' link in an ASP.NET Web Part hosted in SharePoint. One can see an example of this in the Content Editor Web Part and several others that are offered OOB with SharePoint. The purpose is to provide the user a link to quickly edit the properties of the web part initially by opening the editor zone in SharePoint. The same functionality is provided when the page is put in 'Edit' mode and the user selects the web part 'Edit' menu and selects the 'Modify this Web Part' link.

WSS v3 Web Parts, which are derived from the Microsoft.SharePoint.WebParts.WebPart class, make this simple by providing the capability to leverage the ToolPane.GetShowExtensibleToolPaneEvent. This will return the javascript required to perform the required action. Since this is a static reference my first reaction was to put add a reference to the Microsoft.SharePoint namespace in my project and use this code in my ASP.NET web part. It turns out that the first parameter expected by this method is a Microsoft.SharePoint.WebParts.WebPart object. Even though it derives from the System.Web.UI.WebControls.WebParts.WebPart object you can't pass the ASP.NET 2.0 web part as a parameter. This will create a compile time error.

The next step was to leverage the generated javascript code in the ASP.NET 2.0 web part and it should work, right? Not so fast. The javascript that is produced for the Content Editor Web Part is shown below. You can figure this out by right clicking the 'open tool part' link and selecting properties.

javascript:MSOTlPn_ShowToolPane2Wrapper( ‘Edit’, ‘129’, ‘g_59b79f76_b13b_42aa_85f2_f2f1c2ba71f1’);

So we generate the href reference to MSOTlPn_ShowToolPane2Wrapper and pass the parameters; 'Edit', '129' and 'g_59b79f76_b13b_42aa_85f2_f2f1c2ba71f1'. What do those parameters mean? The first is the display mode for the editor pane, the second we'll get to, and the third took a little work. To figure out the second and third I built a web part that output everything that had an ID associated with it; ID, ClientID, etc. Turns out the third variable is just the ID property of the Web Part. One down, one to go.

The second parameter took some more digging and was the bane of my existence for a few hours. I tried several other ID type properties here and nothing worked. I added the web part to a new page so to see if there was a difference in sites (SPWeb) that was generating the ID. Nothing so far. I decided to hook up Fiddler to see what was going on behind the scenes. After all, we have the 'Modify this Web Part' link that does the same thing I wanted to do. After running Fiddler I clicked 'Edit' > 'Modify this Web Part' and looked through the results. Using the known Content Editor Web Part I was able to track down the mysterious '129' parameter. Is was passed in the request as the MSOWebPartPage PostBackSource value. That didn't help much, but I did know where to look now in my custom web part to find the value I needed to pass. Turns out my MSOWebPartPage PostBackSource value was '16'. So I changed the link to be

literal.Text = "<a href=\"javascript:MSOTlPn_ShowToolPane2Wrapper('Edit', '16', '" + this.ID + "')\">open tool pane</a>";

and it worked. Now I just need to find a property with 16 as the value, however, this didn't exist. I turned on the debugger and looked, and looked, and...well, nothing. What is this value? I checked the Web Part Gallery for the site collection to see of maybe the reference was generated there, but my Web part Gallery Id was 88. No luck. The ID for this parameter is being generated somewhere, by something, in order to create the 'Modify this Web Part' menu item. It turns out that you can just pass a reference to 'this' in order to have SharePoint know the post back source. So after changing the code to

literal.Text = "<a href=\"javascript:MSOTlPn_ShowToolPane2Wrapper('Edit', this, '" + this.ID + "')\">open tool pane</a>";

things worked like a charm. There are issues with this implementation. The SharePoint team could decide to change the javascript signature or remove the javascript altogether. In the meantime, this accomplishes the goal and gives the ASP.NET web part SharePoint type functionality.