[another quick update:  be aware that item-level permissions cannot be set/modified via any out-of-the-box Web Service.  The Permissions Web Service (permissions.asmx) can be used to work with permissions on sites or lists, but not items.  I hope to create another post sometime relatively soon on creating custom Web Services in WSS 3.0/MOSS 2007, and perhaps I’ll use the code below in the context of a custom web service for that post as well.]

One of the cool new things in Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 (get your public beta here) — and make no mistake, there are a lot of cool things to go around in these products — is fine-grained (item-level) security.  This was a big big customer wish from the current “v2” versions of the products, and it’s fantastic to see it in the products now.  The whole permissions object model has changed (for the better) as a result, and the product team has built in some great flexibility when working with role-based item-level security via the object model.  I’ve created a quick sample that shows how to set permissions using the various new OM objects and methodologies, and have included it below as an example that can be expanded to other “permissionable” objects within WSS/MOSS as well.

In this sample, I’m going set permissions on a individual SPListItem.  I’ll create or access a Role Assignment (which essentially represents the user), bind a Role Definition to the Assignment (such as "Full Control", "Contribute," etc.), then add the Role Assignment to the object's RoleAssignments collection.  Here’s the code (I’m using a simple C# console app…assume a reference to Microsoft.Sharepoint.dll):

=====

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint;

namespace ListItemPerms
{
    class Program
    {
        static void Main(string[] args)
        {
            SetListItemPerms();
        }

        static void SetListItemPerms()
        {
            //Get SPWeb object

            SPSite Site = new SPSite("http://<url>"); //e.g., "http://myserver/mysite"
            SPWeb Web = Site.OpenWeb();

            //Get Role Definition from SPWeb

            SPRoleDefinition RoleDefinition = Web.RoleDefinitions.GetByType(SPRoleType.Administrator); //or whichever SPRoleType you choose

            //Get SPListItem

            SPList List = Web.Lists["<list name>"]; //e.g., "Announcements"
            SPListItem ListItem = List.Items[1];

            //Create new Role Assignment
            //Add Role Definition to Role Assignment's Role Definition Bindings

            SPRoleAssignment RoleAssignment = new SPRoleAssignment("<login name>", //e.g., "MYDOMAIN\UserA"
                                                                    "<email address>", //e.g., "usera@example.com"
                                                                    "<display name>", //e.g., "User A"
                                                                    "<notes>"); //e.g., "Here are some notes."

            RoleAssignment.RoleDefinitionBindings.Add(RoleDefinition);

            //Check for permission inheritance, and break if necessary

            if(!ListItem.HasUniqueRoleAssignments)
            {
                        ListItem.BreakRoleInheritance(true); //pass true to copy role assignments from parent, false to start from scratch
            }           

            //Add Role Assignment to SPListItem's Role Assignment Collection

            ListItem.RoleAssignments.Add(RoleAssignment);
            ListItem.Update();

        }
       
    }
}

=====

And that’s that!  The user that I specified when creating my new Role Assignment will have Full Control of this single List Item only.  :-)

Web Resources

Way back in the far-distant past, back when all developers had to work with was ASP.NET 1.1 (lo,many ages hence), those developers who wanted to include actual resources — static files such as images, CSS, etc. — with their Web Parts would have to package up the files into an installer package to be included with the Web Part library assembly.  Lucky for us, ASP.NET 2.0 comes with a slick new feature called Web Resources.  Web Resources allow resources to be embedded into the assembly and referenced using a special URL (a nice long convoluted querystring, as you’ll see, but easily referenced via some code magic) from within a web project.  SharePoint developers working with ASP.NET 2.0 Web Parts — for example, those of you who are using pre-Beta 2 releases of Windows SharePoint Services 3.0 or Microsoft Office SharePoint Server 2007 (MOSS), and those of you who will be using the Beta 2 release when it shows up someday soon — can take advantage of the new Web Resources feature to wrap up static files into Web Part assemblies and clean up install processes quite a little bit.  Web Resources include a number of other cool little tricks that make deploying Web Parts with embedded resources simpler and more robust, as well.  Plus, you get to use a cool new thingy — and ain’t that all right, too?

In this post, I’m going to create a Web Part of negligible utility — well…okay, I’m going to create a totally pointless Web Part that will, nonetheless, demonstrate a couple of things that can be done with Web Resources, and hopefully serve as a starting point for those of you out there that have actual problems to solve. :-)

All that my Web Part will do is display an image, and have a bit of client-side script that does a rollover effect when you mouse over the image.  I’m not even going to get so fancy as to have the image be interesting or functional.  We’re just going to have two embedded image resources and one embedded script resource, and have a nice simple Web Part assembly at the end of the day.  I’ll be writing a pure ASP.NET 2.0 Web Part — inheriting from the System.Web.UI.WebControls.WebParts.WebPart class — rather than doing anything SharePoint-specific.  This will be the recommended approach with WSS 3.0 and MOSS 2007 as well — unless a handful of WSS 2.0/SPS 2003 Web Part relics (V2–style Web Part connections, for example…though I have no idea why you’d use those for a new Web Part in WSS 2.0 or MOSS 2007 when the much richer ASP.NET 2.0 connection framework is available to you) are absolutely necessary, ASP.NET 2.0 Web Parts will be the recommended approach, even for Web Part development that makes use of data in WSS 2.0 or MOSS 2007 via the various APIs.

The Resources

I’m going to use two very simple little button images for the purposes of this example. 

The default button image looks like this:

The rollover-state button image looks like this:

The script for doing the rollover is very simple as well:

// Initial JScript source code
function RollOver(imageid)
{
    document.all.item(imageid).src = 'button_hover.gif';
}
function RollOut(imageid)
{
    document.all.item(imageid).src='button.gif';
}

This is saved in a .JS file.  In a minute, I’m going to modify that script to include tags that ASP.NET 2.0 will interpret and substitute with URLs to my embedded image resources at runtime, but for now, it’s enough to see that there’s very little magic going on with the script itself.

Getting the Resources into Visual Studio 2005, and Writing the Code

In Visual Studio 2005, I create a new Web Control Library project.  In my case, I’m going to name it “My.BlogParts.”  Next, I’m going to add a new Resource File to the project, which I can do by going the the menu and clicking Project -> Add New Item… and choosing “Resources File.”  I’m going to name mine “testres.resx.” [I can also create a project default resources file, but for the purposes of this post, it’s just simpler to create a new one]  Once I’ve created it, I can double-click on the testres.resx in Solution Explorer to open up the resources designer.  From within the designer, I then choose Add Resource -> Add Existing File… and add my two .GIF images and my .JS script file to the Resources file.  In the screenshot on the right, you can see what my project’s Solution Explorer looks like after this has been done.  Disregard the additional files in there for now (e.g., RollOver.cs and mykeys.snk), I’ll be discussing them below.  However, do note the added “Resources” folder, as it will become important later on.

For each of the embedded Resource files, I need to set the Build Action for the resource to “Embedded Resource” in the Properties pane for that item.  To do so, I simply select the item from within the Resources folder, look at the Properties pane, and select “Embedded Resource” from the Build Action drop-down menu.  I can leave “Copy to Output” set to its default, which is “Do not copy.”  See the screenshot below:

Since these are Web Resources, I also need to reference them in my AssemblyInfo.cs file.  In this case, here’s the few lines I add:

     [assembly: WebResource("My.BlogParts.Resources.button.gif", "image/gif")]
     [assembly: WebResource("My.BlogParts.Resources.button_hover.gif", "image/gif")]
     [assembly: WebResource("My.BlogParts.Resources.rollover.js", "text/javascript", PerformSubstitution = true)]

The format of these entries is pretty simple.  First param = [Namespace].[Resources Folder].[Resource File Name].  Second param = content type.  Third (optional) param = PerfomSubstitution (true/false).  Because my project, namespace, and assembly will all be named “My.BlogParts,” and my resources folder is named “Resources,” this is pretty easy to figure out:  My.BlogParts.Resources.[resource file name].  The third, optional, parameter lets me do some super-cool runtime substitution that I’ll explain more in a moment.

Now that I have my Resources imported into the Project, I’m going to add and write a simple Web Part that will use them.  Because I hate default names, I’m going to simply delete the “WebCustomControl1.cs” that was created for me when I created the Project, and add a new Web Custom Control to the Project, named “RollOver.cs.”  Visual Studio tries to be nice and adds a bunch of default code into the class file, and in the code snippets below, you might notice that I’ve erased it and started from scratch; for the purposes of this example, though, you could just as well leave all of the default code in the class file and edit the items that I’ve changed and leave the rest since they won’t really hurt anything.

By default, my web control inherits from the System.Web.UI.WebControls.WebControl class.  Because I’m creating a Web Part, I need to change this.  First, I’m going to add a using statement at the top of the .cs file:

Happy coding!

I'll go ahead and open myself up for criticism, I suppose, by noting that I drafted the initial "informal" version of these rules, which then became the basis for the KB article.  The "rules" themselves have almost all been in place as part of the SDK in various places for quite a while but have been more or less A) unnoticed or B) ignored.  Serge's second post on the topic includes a few lines from an email I wrote, which essentially says the same thing:

"The statement that appears to be making the most waves on Serge's blog -- "You modify a custom site definition or a custom area definition after you deploy the custom site definition or the custom area definition" -- was already in place in the SDK (http://msdn.microsoft.com/library/en-us/spptsdk/html/tsovGuidelinesCustomTemplates_SV01018815.asp?frame=true) before this KB article was published; this KB article was, more or less, a reminder and summary of the "rules" that had already been defined in various places throughout the SDK."

So, a couple of things to point out, here.  First, although these things were already extant in the SDK, they were NOT well-placed, well-organized, or in any way easy to comprehend in a unified way.  The mention of site definition rules were scattered throughout the SDK in a number of different places -- the one above being just one of several.  Additionally, when discussing site definitions, the SDK previously used language -- which we've since changed -- that was simply not forceful enough (e.g., using the term "recommendations" rather than "requirements").  The purpose of the SDK language changes and the article above was to bring all of the site definition "Rules and Regulations" into a simple, easy-to-understand article that would lay down the facts once and for all (or...at least, for the time being). 

Because we wanted this to be the "official" statement on site definition rules, we did what good Microsoft employees do;  we argued about it -- sometimes loudly :) -- amongst ourselves.  Then, we got final word buyoff from the product group folks who are ultimately responsible for implementing these things.  It's fair to say that there were very strong and vocal arguments about nearly all of these items, but particularly about the item above, "changing a site or area definition after it has been deployed."  Lots and lots of people love being able to make a change to a central site definition and have that change automatically populated throughout any sites that have been created using that definition.  No doubt, that's a cool thing.

Unfortunately, it is not something that the product was designed to do.  The folks who wrote and designed this product don't like the idea, and have strong enough concerns about the stability of the product when used in such a way that they've been willing to continue to tell us that it is unsupported even in the face of fairly strong external *and* internal pressures.  We decided that we'd rather have the SharePoint community upset about the support policy itself than have folks in the SharePoint community find themselves in unsupported scenarios or with unexpected and potentially unsupported problems precisely because Microsoft hadn't done a good enough job getting out the message about supportability where site and/or area definitions are concerned.

All that being the case, what some other of my colleagues and MVPs have said is true;  there remain supported ways to make changes to a wide number of sites in a SharePoint deployment -- the object model/API being the foremost among them.  Is this a perfect answer?  Of course not!  Making a global change by modifying a line or two in the ONET.XML file sure is easier than writing 100 lines of OM/API code to do the same thing.  Anyone who has ever tried to do something as conceptually simple as copy a list from one site to another with the OM/API knows that simplicity is in the eye of...well, no one.  But we are assured that if any problems occur when running our OM/API code, it will be 100% supportable -- and that, Martha would say, is a good thing.

Here's hoping the situation improves in future versions of the product.  :)

-R

I'll add to this list from this point on, unless a better solution comes by way of new functionality on Community Server. 

Newest posts are at the top.

=====

• CopyCat: Using Built-in WebServices to Copy Document Library Permissions Across Servers
• Alert Me: Parameters Passed to SearchAlertType.GetAlertCreationLink()
• Finding Ghosts: Programmatically Determining Ghosted/Unghosted State
• Drawing the Curtain: Removing Access to the Site Settings Page for non-Administrative Users
• What's on the Menu? - How to Remove Items from a Document Library Drop-down Menu
• UPDATE: Get your MSSQLFT Documentation While it's Hot (and I'll bet it is)
• Expanding Horizons: Restrict a Customized Search to an Individual, New, Programatically-Created Content Source
• Adding New List Items Using the Lists.asmx Web Service
• So, DoesUserHavePermissions() or Not?
• MSSQLFT Syntax School -- How to Get Ahead in Search
• Creating a Modal Dialog "Chooser" Tool Part

The sample does the following:

-Gets the current destination list permissions using the web service on the destination site

-Removes the current destination list permissions using the web service on the destination site

-Gets the source list permissions using the web service on the source site

-Sets the destination list permissions using the web service on the destination site

This project will require adding a Web Reference -- to the Permissions web service on any machine (the URL will be overwritten in the code) -- in the VC# project.  Adding the Web Reference should add standard references to System.Web.Services, System.XML, and System.Data.

Two notes on this sample:

1) There is little error handling.

2)  We cannot remove or add implicit members (Administrator, Guest) of a list. These members are automatically added when a list is created, and are not controlled by the user; as such, they can not be programmatically modified.

=====

using System;

using System.Xml;

using System.Diagnostics;

namespace CopyDocLibPermissions

{

public class AddWithWS

{

[STAThread]

static void Main(string[] args)

{

string sSourceSiteURL = "http://<server>/sites/<site1>"; //TODO: modify

string sSourceList = "MySourceList"; //TODO: modify

string sDestSiteURL = "http://<server>/sites/<site2>"; //TODO: modify

string sDestList = "MyDestinationList"; //TODO: modify

int iReturn = CopyPermissions(sSourceSiteURL, sSourceList, sDestSiteURL, sDestList);

Console.ReadLine();

}

static int CopyPermissions(string SourceSite, string SourceList, string DestSite, string DestList)

{

//get permissions from destination list

System.Xml.XmlNode xDestPerms = GetPermissions(DestSite, DestList);

//remove existing permissions from destination list

RemovePermissions(DestSite, DestList, xDestPerms);

//get source list permissions

System.Xml.XmlNode xSourcePerms = GetPermissions(SourceSite, SourceList);

//add source list permissions to destination list

SetPermissions(DestSite, DestList, xSourcePerms);

Console.WriteLine("==COMPLETE!==\n");

return 0;

}

static XmlNode GetPermissions(string URL, string ListName)

{

URL += "/_vti_bin/Permissions.asmx";

localhost.Permissions oPermissionsService = new localhost.Permissions();

oPermissionsService.Url = URL;

oPermissionsService.Credentials = System.Net.CredentialCache.DefaultCredentials;

try

{

XmlNode oNode = oPermissionsService.GetPermissionCollection(ListName, "List");

return oNode;

}

catch(System.Exception exGet)

{

Console.WriteLine("Error Getting Permissions!");

Debug.WriteLine(exGet.ToString());

return null;

}

}

static bool RemovePermissions(string URL, string ListName, XmlNode Permissions)

{

URL += "/_vti_bin/Permissions.asmx";

localhost.Permissions oPermissionsService = new localhost.Permissions();

oPermissionsService.Url = URL;

oPermissionsService.Credentials = System.Net.CredentialCache.DefaultCredentials;

XmlNodeList xNL = Permissions.FirstChild.ChildNodes;

string sPerm = "";

string sIsUser = "";

string sName = "";

string sType = "";

for(int i=0;i<xNL.Count;i++)

{

sIsUser = xNL[i].Attributes["MemberIsUser"].Value.ToString().ToUpper();

if(sIsUser == "TRUE")

{

//is user

sName = xNL[i].Attributes["UserLogin"].Value.ToString();

sType = "user";

}

else

{

sPerm = xNL[i].OuterXml.ToString();

if(sPerm.IndexOf("RoleName") > 0)

{

//is Role

sName = xNL[i].Attributes["RoleName"].Value.ToString();

sType = "role";

}

else

{

//is group

sName = xNL[i].Attributes["GroupName"].Value.ToString();

sType = "group";

}

}

try

{

oPermissionsService.RemovePermission(ListName, "List", sName, sType);

Console.WriteLine("Permission Removed: {0}", sName);

}

catch(System.Exception exRemove)

{

Console.WriteLine("Can't Remove Permission: {0}",sName);

Debug.WriteLine(exRemove.ToString());

}

}

return true;

}

static bool SetPermissions(string URL, string ListName, XmlNode Permissions)

{

URL += "/_vti_bin/Permissions.asmx";

localhost.Permissions oPermissionsService = new localhost.Permissions();

oPermissionsService.Url = URL;

oPermissionsService.Credentials = System.Net.CredentialCache.DefaultCredentials;

XmlNodeList xNL = Permissions.FirstChild.ChildNodes;

string sPerm = "";

string sIsUser = "";

string sName = "";

string sType = "";

int iMask = 0;

for(int i=0;i<xNL.Count;i++)

{

sIsUser = xNL[i].Attributes["MemberIsUser"].Value.ToString().ToUpper();

iMask = Int32.Parse(xNL[i].Attributes["Mask"].Value);

if(sIsUser == "TRUE")

{

//is user

sName = xNL[i].Attributes["UserLogin"].Value.ToString();

sType = "user";

}

else

{

sPerm = xNL[i].OuterXml.ToString();

if(sPerm.IndexOf("RoleName") > 0)

{

//is Role

sName = xNL[i].Attributes["RoleName"].Value.ToString();

sType = "role";

}

else

{

//is group

sName = xNL[i].Attributes["GroupName"].Value.ToString();

sType = "group";

}

}

try

{

oPermissionsService.AddPermission(ListName, "List", sName, sType, iMask);

Console.WriteLine("Permission Added: {0}", sName);

}

catch(System.Exception exAdd)

{

Console.WriteLine("Can't Add Permission: {0}",sName);

Debug.WriteLine(exAdd.ToString());

}

}

return true;

}

}

}

strQueryWhereClause   WHERE clause for the search query this alert describes.

strViewThisSearchResultsURL   URL for the search result that this alert describes.

strSuggestedTitle   Suggested link text.

strXMLEditQueryData   XML representation of the edit query data.

The first three of these I can figure out just fine.  The fourth, though, is pretty cryptic.  What exactly does "XML representation of the edit query data" mean?  How am I supposed to write any sort of "representation" if I haven't been given an example of the format?

Well, if we get sneaky and look around a bit, we can find the format hiding in the HTML source.  Here's how.

Let's do a search (in my case, I'm searching the portal for "test").  When we get the results, an Alert Me link will be on the left-hand pane.  Like a good sleuth, I'm going to "View Source" in IE.  The HTML source for the Alert Me link looks like the following (FIND: Alert Me):

<a id="_ctl7:sch_mgmt_subs" class="" href="javascript:schOnSubscribeSearch();" mce_href="javascript:schOnSubscribeSearch();" accesskey="u" title="To be notified when new results are available or existing results change">Alert Me</a>

Alright.  Now we're getting somewhere.  The link calls a JScript -- I know it says javascript, but I'm sure they meant to say JScript, right? :) -- method schOnSubscribeSearch().  Another hunt through the HTML source yields this function (FIND: schOnSubscribeSearch):

function schOnSubscribeSearch()

{

window.location.href = "javascript:spslcLBP\(&#39;&#39;,&#39;&#39;,&#39;Search&#39;,&#39;&#39;,&#39;

http:\\\/\\\/sharepointblank\\\/Search.aspx?k=test&amp;s=All%2520sources&#39;,&#39;test&#39;,&#39;

Search for \\&quot;test\\&quot;&#39;,ax0\(\)\);";

}

Sweeeet.  Now, that's some good looking stuff.  If we get rid of some encoding, these parameters look something like:

spslcLBP("",

"",

"Search",

"",

"http://sharepointblank/Search.aspx?k=test&s=All sources",

"test",

"Search for "test"",

ax0());

Some more hunting, and I can find the spslcLBP function, in linkcreator.js.  Its parameter list looks like this:

function spslcLBP(

oItem,

sUrl,

sAlertType,

sObjectDefinition,

sObjectUrl,

sObjectDisplay,

sSuggestedTitle,

sXmlParameters)

A bit more looking into the HTML/JavaScript source, and I can determine that the last of these parameters is what I'm looking for -- in otherwords, if I can find what sXmlParameters looks like, I know what strXMLEditQueryData parameter should look like.  In my spslcLBP that got rendered to the page, the sXmlParameters parameter is "ax0()".  This looks like another JScript function, so here I go searching through the HTML source of the page again (FIND: ax0()), and I find the culprit:

<SCRIPT DEFER>function ax0() { return 'PFNlYXJjaE9wdGltaXphdGlvbj48

VGVybXM+dGVzdDwvVGVybXM+PFF1ZXJ5SW5mbz4gDQooKCJ1cm46c2N

oZW1hcy1taWNyb3NvZnQtY29tOnB1Ymxpc2hpbmc6SG9tZUJlc3RCZXRLZ

Xl3b3JkcyI9IHNvbWUgYXJyYXkgWyd0ZXN0J10gUkFOSyBCWSBDT0VSQ0l

PTihhYnNvbHV0ZSwgOTk5KSkNCk9SIChGUkVFVEVYVCgidXJuOnNjaGVtY

XMtbWljcm9zb2Z0LWNvbTpzaGFyZXBvaW50OnBvcnRhbDpwcm9maWxlOl

ByZWZlcnJlZE5hbWUiLCAndGVzdCcpIFJBTksgQlkgQ09FUkNJT04obXVsdGl

wbHksIDAuMDEpKQ0KT1IgRlJFRVRFWFQoI1dlaWdodGVkUHJvcHMsICd0ZX

N0JykgKQ0KIA0KICA8L1F1ZXJ5SW5mbz48L1NlYXJjaE9wdGltaXphdGlvbj4

=';}</SCRIPT>

Very nice.  Base64-encoded data.  Let's decode that bad boy and see what happens.  Once decoded from Base64, it looks like this [I've formatted with line breaks/indents]:

<SearchOptimization>

  <Terms>test</Terms>

  <QueryInfo>

    (("urn:schemas-microsoft-com:publishing:HomeBestBetKeywords"= some array ['test'] RANK BY       COERCION(absolute, 999))

OR (FREETEXT("urn:schemas-microsoft-com:sharepoint:portal:profile:PreferredName", 'test') RANK BY COERCION(multiply, 0.01))

OR FREETEXT(#WeightedProps, 'test') )

  </QueryInfo>

</SearchOptimization>

So, there's our format.  As regards the GetAlertCreationLink() method of the Microsoft.SharePoint.Portal.Alerts.SearchAlertType class, the fourth argument, strXMLEditQueryData, should have the following format:

<SearchOptimization>

  <Terms></Terms>

  <QueryInfo></QueryInfo>

</SearchOptimization>

Ghosted:  a ghosted page is one that is read directly from the site definition on the filesystem.

Unghosted:  an unghosted page is one that is read from the SharePoint database and *not* a physical file

So, how can we determine if a given page is either ghosted or unghosted?  Luckily, there is a single property that will tell us:  "vti_hasdefaultcontent."  If this property exists on a file, it is ghosted (again, on the filesystem);  if the property does not exist, the file is being served from the database.

Here's the code for a simple command-line utility that will take the URL to a given page and report whether it is ghosted or unghosted:

=====

using System;

using Microsoft.SharePoint;

namespace GhostCheck

{

public class Checker

{

[STAThread]

static void Main(string[] args)

{

//if vti_hasdefaultocontent = true, it is ghosted;  if unghosted, the prop doesn't exist

if(args.Length == 0 || args[0].ToString().Equals("/?"))

{

Help();

}

else

{

string sURL = args[0].ToString();

bool hasError = false;

string sGhosted = CheckGhost(sURL, out hasError);

if(hasError)

{

Console.WriteLine("\nError encountered: {0}", sGhosted);

}

else

{

Console.WriteLine("\nThe page at {0} is {1}", sURL, sGhosted);

}

}

}

static  void Help()

{

Console.WriteLine("\nghostcheck <URL>");

Console.WriteLine("\nExample:  ghostcheck http://<myserver>/sites/<site>/Lists/Contacts/NewForm.aspx");

}

static string CheckGhost(string FileURL, out bool ErrorFlag)

{

ErrorFlag = false;

SPSite oSite = null;

SPWeb oWeb = null;

SPFile oFile = null;

try

{

oSite = new SPSite(FileURL);

}

catch(System.Exception exSite)

{

ErrorFlag = true;

return String.Format("Error getting Site: {0}", exSite.Message);

}

try

{

oWeb = oSite.OpenWeb();

}

catch(System.Exception exWeb)

{

ErrorFlag = true;

return String.Format("Error getting Web: {0}", exWeb.Message);

}

try

{

oFile = oWeb.GetFile(FileURL);

}

catch(System.Exception exFile)

{

ErrorFlag = true;

return String.Format("Error getting File: {0}", exFile.Message);

}

System.Collections.Hashtable oHash = oFile.Properties;

if(oHash.ContainsKey("vti_hasdefaultcontent"))

{

return "ghosted (on file system)";

}

else

{

return "unghosted (in database)";

}

}

}

}

=====

This utility uses the SharePoint object model, and so MUST BE RUN ON THE SERVER, not from a client.

Usage:

ghostcheck.exe <URL>

Example:

ghostcheck.exe http://myserver/sites/mysite/Lists/Contacts/NewForm.aspx

You might have noticed that authenticated users granted Reader access to a SharePoint site also have access to the Site Settings page:  _layouts/<LCID>/settings.aspx.  Although these users will typically have no rights to access any of the pages linked therein, it might be desirable to remove access to the settings.aspx page altogether, so that non-Administrative users don't even have the option to see what can be done from an administrative perspective.  Honestly, I'm really not sure why this page is able to be viewed by non-Administrative users to begin with, but that's irrelevant;  it is viewable, and I want to change that.

I have two options, one supported and one unsupported

1)  Somewhat complicated, but supported:  write a wildcard-mapped ISAPI extension

2)  Simple, but strictly not supported:  drop a CheckPermissions() call onto the settings.aspx page

I've covered both of these options in more detail below:

*****

ISAPI Extension

Although writing an ISAPI extension isn't a particularly simple task, and requires knowledge of C++ programming, etc., it is a possible (and supported) solution.  Essentially, I would need to create an wildcard-mapped ISAPI extension that examined each request.  I would start by checking the requested URL by looking in the VTI_SCRIPT_NAME server variable.  If that request was for a _layouts page (settings.aspx in particular), my ISAPI extension could check the authentication type and/or authentication user from the server variables (AUTH_TYPE, and AUTH_USER). 

If, for example, the AUTH_USER server variable were blank, the ISAPI extension could redirect by posting a 302 Redirect to some other URL -- including, for example, a custom error page somewhere.

The IIS SDK includes ISAPI extension samples, including a wildcard-mapped ISAPI extension sample.  Here's a link to the Platform SDK Update site, where you can obtain any of the various platform SDK modules:

http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

I would start with the WildcardMap sample provided in the SDK (...\Microsoft SDK\Samples\web\iis\ISAPI_6.0\WildCardMap).  This sample is specifically designed to capture *every* request.  To use this with IIS, I'll need to register the built ISAPI extension within IIS. 

NOTE: With Windows Server 2003 and with SharePoint Portal Server (or Windows SharePoint Services), there are some additional steps required to get the ISAPI extension functioning, which I cover below.

Once built, I can simply open up the IIS management console, right-click the web site I want to register the ISAPI with to get the web site properties, and choose the "Home Directory" (or "Virtual Directory" if this is a virtual directory rather than a web site) tab. 

Click the "Configuration..." button to open the "Application Configuration" dialog.  Under the "Wildcard application maps" section, choose "Insert..." and enter the path to my built DLL (or choose "Browse..." to find it).  IMPORTANT:  to use an ISAPI extension with Sharepoint, I must UN-check the "Verify that file exists" checkbox.

Apply all of those changes to the web site or virtual directory.

Next, in IIS management console, I select "Web Server Extensions."  This will bring up a list of the allowed and prohibited extensions.  I'll need to click on "Add a new Web service extension..." give the Extension a name, provide a link to the built DLL, and set the status to "Allowed."

At that point, my ISAPI extension should be ready to work.

CheckPermissions()

There *is* an alternative workaround, which -- unfortunately -- is not supported by Microsoft.  If I open one of the various administrative ASPX pages in Visual Studio.NET (or Notepad, for that matter) and view the code, I can see that there is an explicit check for role-based permissions.  For example, in User.ASPX, which is located at x:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Template\Layouts\1033\user.aspx, the line of code which checks permissions looks like this:

=====

<% spWeb.Permissions.CheckPermissions(SPRights.ManageRoles); %>

=====

This line checks to see if the current user has the ManageRoles right.  If so, the user is allowed to view the page;  if not, the user is prompted for authentication.  In contrast, the Settings.aspx page -- the first that a user sees after clicking on "Site Settings" in a WSS site -- contains no such permissions check.

The SPRights enumeration is covered in the MSDN Library at the location below:

=====

SPRights Enumeration

=====

This enumeration contains various rights that can be assigned to a user.  For example, the ViewPages right allows a user to view pages within a WSS Site.  It would be possible -- though, again, not supported -- to add a line of code like the one above to the various administrative settings pages that you wanted to restrict to Administrative users only.  For instance, if I wanted to restrict access to the Settings.aspx page only to users who have the ManageWeb right, I could include the following line of code in settings.aspx (existing/surrounding code included for reference, new code in bold):

=====

SPWeb spWeb = SPControl.GetContextWeb(Context); %>

<% spWeb.Permissions.CheckPermissions(SPRights.ManageWeb); %>

<HEAD>

=====

With this code in place, when a user attempts to go to the settings.aspx page, Sharepoint will check to see if they have the ManageWeb right;  if so, they can view the page -- if not, they'll be denied access and prompted for credentials.

The big caveat, as I've mentioned, is that this solution is not supported by Microsoft.  We do not support making any direct modifications to the code used in any of the pages in the LAYOUTS directory.  What this means is that if you were to apply this change and later were to run into any problems on your server, Microsoft PSS would require that the change be rolled back before any assistance could be given.  Additionally, Microsoft has reserved the right to overwrite any of the default (out-of-the-box) files located in the LAYOUTS directory in any future service packs or updates.  Such an overwrite would wipe out changes, so I would need to be aware of the changes that I've made so that I could re-implement in such a case.

*****

There is one scenario in which this isn't an issue:  Anonymous access over the internet.  If I have setup a SharePoint site to allow anonymous authentication, and a user browses to my site, they can view pages such as default.aspx just fine.  As soon as they attempt to view settings.aspx, though, they will be prompted.  Because the user is not on my domain, Windows Integrated authentication cannot negotiate authentication to settings.aspx, and the user will be prompted.