SharePoint Designer: Can You Live with It? Can You Live without It?

Striking a Balance, Maximizing Effectiveness and Eliminating Headaches, Part One

Summary: SharePoint Designer (SPD), whose progenitor was Microsoft FrontPage, provides an application that can be used by web designers and others who need to modify SharePoint beyond what can be done in the native web-based SharePoint user interface. Network administrators have every reason for the concerns they often raise about the use of SharePoint Designer though. The Contributor Settings feature of SPD provides a means of establishing a secured and balanced approach to this issue.

I’m not going to try and answer either of the questions for you. You have to make that decision yourself based on what your responsibilities are, the best practices and governance you follow in your organization, and any accommodations you want to make. Make no mistake SharePoint Designer is a double-edged sword. If you’re cavalier when using it, you’ll likely get cut deeply. If you are attentive, you can save yourself and your organization time and money. It’s not my purpose here to discuss all that SharePoint Designer can do nor the potential dangers it presents. There are books, published and soon-to-be- published, that you should consult if you are interested in these topics. There is also a SharePoint Designer Team Blog you might want to spend some time reading as well.

My only recommendation here is that you understand fully what you are accepting or rejecting before you decide. The Designer is not your father’s FrontPage, to hack-up a phrase.

So what is this blog about? It’s about control: how you can very effectively and very granularly control the use of SharePoint Designer.

Background

The broad use of FrontPage 2003 to customize SharePoint 2003 was well underway in many organizations before the implications of doing so were fully understood. One of the most sought after bits of information used to be the name of the attribute that could be used in site definitions’ onet.xml files to lockout FrontPage entirely. That attribute, DisableWebDesignFeatures, can still be used today with SharePoint 2007. The possible values for that attribute are listed below; wdfopensite prevents any site of the type defined by the onet.xml file from being opened in SharePoint Designer, just as it did for FrontPage 2003.

The two screen shots below show the attribute with wdfopensite applied in an onet.xml file and the message displayed to the user in SharePoint Designer, respectively.

The only problem with the attribute is that it locks down all the sites (SPWeb) that use that site definition regardless of the site collection or web application in which they are located. That might be more than is needed or even desired.

Contributor Settings

SharePoint Designer (SPD) itself provides a solution to this problem. One of the features of SPD is the ability to control what it can modify and by whom. The feature that provides this capability is known as Contributor Settings, a somewhat misleading term since Contributor here is a generic term unrelated to the SharePoint Contribute permission, although the Contribute permission is used in Contributor Settings. Confused? Well it’s probably not your first time with SharePoint. You can read more about this feature here: Introduction to Contributor Settings, but let’s take a quick look at what it offers.

Contributor Settings are enabled by default in SPD although they can be disabled by an administrator. I’m not going to go into great detail here but by default there are three types of contributors defined in SPD; in decreasing permission level they are Site Manager, Web Designer and Content Authors. Content Authors are any SharePoint users with the Contribute permission; Web Designers are SharePoint users with the Design permission. Again for details regarding the SPD contributors and mappings to SharePoint permissions follow the link above and its links. What is important here is that every SharePoint permission, even custom permissions can be mapped to a SPD contributor, either one of the defaults or custom contributors you create, say IntranetPublish. The set of three screen captures below shows where to find the Contributor Settings dialog windows and what some of those dialogs contain. Note the different capabilities of the Content Author as opposed to the Site Manager and the mappings to the SharePoint permission.

SPD uses the types of contributors to control what can be modified within SPD by those contributor types. Furthermore it is possible to modify the default settings that SPD provides. The next two graphics provide a brief look at both the granularity of control and the process of modifying some of the default settings for the contributor type, Web Designer. Note that here the Web Designers are limited to editing pages that are located in the Pages or Documents libraries only and that they cannot change the web part zone configuration. These are just a few examples of how SPD can be used to lock itself down so to speak. There are many, many other configurable options.

Pluses and Minuses

The granularity of control provided by SPD Contributor Settings is much finer than that that the attribute DisableWebDesignFeatures allows. Additionally, they are applied at the site (SPWeb) level. The only site for which changes were made in the screen shot sequence above was http://moss/sales. Its parent and its sub-sites were left unaffected as were all sites in other site collections or web applications.

This presents the opposite problem that DisableWebDesignFeatures presented in terms of scope. Inheritance of settings from a parent site is not possible with SPD Contributor Settings. That means each site’s SPD Contributor Settings has to be individually configured. The bottom line is that it requires an extensive, probably prohibitive, level of effort to maintain control over all sites in a farm using SPD’s Contributor Settings if you want to do anything but use the default configuration and in my opinion the default configuration is probably too permissive for many organizations.

Programmatic Modification of Contributor Settings

All is not lost however because we can set the Contributor Settings programmatically, though not using the approach you might think. The object model (OM) for SharePoint is quite powerful. It doesn’t allow total programmatic control however and it can’t be used in all situations. If you can’t find a means of doing something through the OM, you can usually find a way through the web services that SharePoint provides. Still, there are times when neither the OM nor web services will let you do what you need to do programmatically. In these situations it’s necessary to turn to other methods and in this particular case to the webDAV RPC (Remote Procedure Call) approach.

I don’t have a solid empirical measure but a web search using a couple of different engines produced from 1 to 2 orders of magnitude difference in the number of hits for "SharePoint 2007" and webDAV compared to "SharePoint 2007" and object model, the latter yielding the higher hit-count. So I’m going to conclude for the purposes of this blog that webDAV isn’t getting much attention in the SharePoint 2007 arena. Since it’s the only way to get ourselves out of the box that the SPD Contributor Settings puts us in however we’re going to have to use it. In the remainder of this blog I’m going to review briefly webDAV and its use with SharePoint 2007. In a later blog I’ll present the code and the webDAV methods necessary to programmatically set SPD’s Contributor Settings.

webDAV

If you dig deep into the Windows SharePoint Services (WSS) SDK you’ll find a section covering protocols. There you can find information about the RPC protocols that can be used with SharePoint. Unfortunately it’s not particularly detailed so whenever you need to use one of the two RPC protocols (or either of the other two) you’ll likely need to make use of a packet sniffer as well and use a little trial and error. If you’re persistent you can usually determine what you need to do in 15 to 30 minutes.

The webDAV RPC uses HTTP POST requests to send methods to WSS. There are a number of operations that can be performed with these requests and as you would expect a number of parameters that are available for use with the method request. The response contains information in an HTML document. If successful, the returned page will contain either or both of the following:

1. a message that the method completed successfully;
2. the name of the request method and a bulleted list of keys and values for the object upon which the method acted.

The universe of keys, that is possible metadata, is also very large, nearly 150 different items each of which begins with the prefix vti_. If the request is unsuccessful, a standard error message format is returned in the response; it contains the method name and the status code.

Included in each request is a server version code identifying the exact version of WSS in use on the server. The form is major.minor.phase.increment. WSS 3.0 (pre-SP1) uses 12.0.0.4518 for the server version code.

The basic approach is to instantiate an HttpWebRequest object, set its properties and call the request object’s GetResponse method assigning an HttpWebResponse.

Here’s a code snippet for a webDAV request

string _method = "method=set+service+meta-info:12.0.0.4518&service_name=/saless&meta_info=[vti_safeeditingconfigfileurl;SW|_contributor_settings/FA67C7A2-41B9-4314-A070-155B60A7A26F.htm]";

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

string _authorDLL="http://moss/saless/_vti_bin/_vti_aut/author.dll";

string _headerContentType="X-Vermeer-Content-Type";

string _headerCT_value = "application/x-www-form-urlencoded";

HttpWebRequest _request = HttpWebRequest.Create(_authorDLL) as HttpWebRequest;

_request.ContentLength = _method.Length;

_request.ContentType = "application/x-www-form-urlencoded";

_request.Headers.Add(_headerContentType, _headerCT_value);

_request.Credentials = CredentialCache.DefaultCredentials;

_request.Method = WebRequestMethods.Http.Post;

This is what the actual request looks like as seen from Fiddler2 (the raw request with headers) and a portion of the response returned.

Request:

POST /saless/_vti_bin/_vti_aut/author.dll HTTP/1.1

Content-Type: application/x-www-form-urlencoded

X-Vermeer-Content-Type: application/x-www-form-urlencoded

Authorization: NTLM TlRMTVNTUAADAAAAAAAAAEgAAAAAAAAA

SAAAAAAAAABIAAAAAAAAAEgAAAAAAAAA

SAAAAAAAAABIAAAABcKIogUCzg4AAAAP

Host: moss

Content-Length: 209

Expect: 100-continue

method=set+service+meta%2dinfo%3a12%2e0%2e0%2e4518&service%5fname=%2fmktg&meta%5finfo=%5bvti%

5fsafeeditingconfigfileurl%3bSW%7c%5fcontributor%5fsettings%2fC11F0E2C%

2d6565%2d4FED%2d987E%2d79D4E3570E22%2ehtm%5d

Response:

<html><head><title>vermeer RPC packet</title></head>

<body>

<p>method=set service meta-info:12.0.0.4518

<p>meta_info=

<ul>

<li>vti_defaultlanguage

<li>SW|en-us

<li>vti_servercharsets

<li>VX|windows-1257 iso-8859-5 big5 windows-1252 iso-8859-9 windows-874 utf-8 windows-1251 windows-1256 iso-8859-4 gb2312 windows-1253 windows-1258 koi8-r iso-8859-1 iso-8859-6 iso-8859-8 ks_c_5601-1987 gb18030 iso-2022-jp windows-1250 windows-1255 us-ascii euc-jp unicode unicodeFFFE windows-1254 iso-8859-2 iso-8859-7 iso-8859-15 shift_jis euc-kr

<li>vti_toolpaneurl

<li>SX|http://moss/mktg/_layouts/toolpane.aspx

<li>vti_assemblyversion

<li>SX|Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c

<li>vti_associatevisitorgroup

<li>SW|4

The primary wevDAV methods I will use to set SPD’s Contributor Settings are:

• create url-directories
• put document
• set docsmetainfo
• set servicemeta-info

We’ll look at these in the next blog in this series.