Skip Ribbon Commands
Skip to main content
www.iwkid.com > Blog > Posts > Behind the scenes – blocking SharePoint Designer Access
April 14
Behind the scenes – blocking SharePoint Designer Access
by  Raymond MitchellNo presence information  on 4/14/2009 7:29 AM

Late last week Brian Caauwe and I spent some time looking into how to lock down SharePoint Designer access.  One of the first options that is available is to modify a Site Definition’s ONET.xml file.  All of the instructions are available here (thanks to the SharePoint Designer Team!) so I’m not going to walk through each step – the main thing to note is that we’re updating the Project element to include a new attribute, “DisableWebDesignFeatures” which you can see here:

image

 

Once the new attribute is in place (and IIS is reset), any attempt to open the site in SharePoint Designer gives you a very friendly error message:

image 

 

What is great is that if you update the Site Definition and remove the “DisableWebDesignFeatures” attribute (and reset IIS), the site will open in SharePoint Designer just fine.  I did not think that was the case so I was pretty interested to see what exactly was going on behind the scenes.

So how does SharePoint Designer know when it is ok to open?  To find that answer we can turn to our best friend, Fiddler.  By using Fiddler while we attempt to open a site with SharePoint Designer, we can see that a number of RPC calls are made:

image

 

The third RPC call (the one to author.dll) is the one we’re most interested in: it calls the Open Service FPRPC method.  The response we get is almost 3kb of ALMOST-html garble (thanks again, Vermeer).  Hidden in the response is a familiar attribute with a new name – vti_disablewebdesignfeatures2 with a value of wdfopensite:

image 

 

If we were to remove the attribute from our ONET.xml file and then reset IIS, the attribute also goes away from our Open Service request.  Here’s where Brian stepped in with the best idea ever – can we possibly set the same variable in an SPWeb’s PropertyBag?  I thought he was crazy but, as is frequently the case when I question Caauwe, I was wrong!

First I opened up PowerShell and looked at the properties stored in an SPWeb’s PropertyBag:

image

From there I added a new property matching the existing “vti_” pattern, using the property name we found in the Open Service method’s response:

image

and now, without an IIS reset, I get our friendly error message stating that access via SharePoint Designer has been disabled:

image

 

Brian and I used this new found knowledge to create a new release for the NoSPD Codeplex project that wraps this functionality into a feature.  Check it out here!

Permanent Link to Post | Email Post Link | Number of Comments 4 Comment(s)

Comments

Blocking SharePoint Designer

Great article. I mistakenly broke into the Website (built on SharePoint) of a major international company last week after opening their site in designer.

You might want to see my SharePoint blog about Designer this week

http://aboutsharepoint.com
 on 4/14/2009 7:43 AM

Re: Behind the scenes – blocking SharePoint Designer Access

Very interesting! I'll be sure to check this out when I get 5 mins. It's still pretty awful that Microsoft didn't give us a native way of achieving this, particularly when you learn how simple it is to control.

Thanks
 on 4/14/2009 7:46 AM

blocking SharePoint Designer Access

Hello,  I installed this feature in my dev sharepoint environment. Is it possible to make this feature work as a web application feature instead of a site feature?  I have many site collections with an unknown number of sub sites.  I would love to be able to stop access at the web level and not have to go to each site. 
Thanks, very nice blog by the way.
 on 5/20/2009 1:39 PM

Web Application Feature

Hi Mike - yes, you could write a web application feature that goes through each of the existing webs and disables SPD but you'd probably also want to associate a stapling feature that took care of newly created webs...
Raymond MitchellNo presence information on 5/20/2009 2:59 PM

Limit Specific Designer Features

Thanks for the helpful post!  Do you happen to know if there is a way to limit the use of Designer to specific areas?  For example, we do not want our users to edit the page/design of their SharePoint sites, however we would like to allow them to use the Designer Workflows. 
 on 7/13/2009 8:19 AM

Limit Specific Designer Features

Thanks for the helpful post!  Do you happen to know if there is a way to limit the use of Designer to specific areas?  For example, we do not want our users to edit the page/design of their SharePoint sites, however we would like to allow them to use the Designer Workflows. 
 on 7/13/2009 9:14 AM

Limit Specific Designer Features

Thanks for the helpful post!  Do you happen to know if there is a way to limit the use of Designer to specific areas?  For example, we do not want our users to edit the page/design of their SharePoint sites, however we would like to allow them to use the Designer Workflows. 
 on 7/13/2009 11:32 AM

Limit Specific Designer Features

Thanks for the helpful post!  Do you happen to know if there is a way to limit the use of Designer to specific areas?  For example, we do not want our users to edit the page/design of their SharePoint sites, however we would like to allow them to use the Designer Workflows. 
 on 7/13/2009 11:32 AM

Disabling SharePoint features of a Site from Designer?

Raymond,
  Our original SP admin installed every feature under the sun so that we could play with it. Now we want to migrate some of the test sites to a newly installed SP site with only the minimal features that we bought licenses for. How can we export or import a site that is referencing many unused and now uninstalled features?
We tried both export/import from stsadm and also Designer.

Thank you! Irene
 on 7/27/2009 7:56 PM