Browse Directories Permission and Webs.GetWebCollection strangeness

I’ve had a support call from a client; an application that I’d written wasn’t letting some users see the subsites of a particular site. However, in the web browser, they could see (and navigate) to those sites. “Strange”, I thought, “they must’ve misconfigured their permissions”. Well, they hadn’t.

My app communicates with SharePoint via the Web Services, and tracking through my code showed me that the problem was coming from the Webs.GetWebCollection call. As this problem was only affecting some users – notably, those who’d have limited rights, I wondered if this was a permission issue. It seemed strange though; users could still see the sub-sites, either in the navigation menus or in the ‘View all site content’ page.

Digging further into permissions, I found that users with ‘Read’ rights got errors with my application. I decided to set up a test system.

I created a site collection with three ‘levels’ of sites (Gateway, Branch, Subsite). For my test, I would use the Gateway site, the Branch A site inside it, and the Subsite 1 site inside that. Thus, they looked like:

Gateway > Branch A > Subsite 1

I then created four users and gave them different memberships on the different sites:

Gateway Branch A Subsite 1
Alice Member Member Member
Bob Visitor Member Member
Chan Visitor Visitor Member
Dina Visitor None Visitor

As usual, Members have Contribute rights and Visitors have Read rights

I tried logging into SharePoint through the web browser as the different users to see what I could see in the navigation. Alice, Bob and Chan all saw the same:

Alice's view of the navigation in the web browser

All these users could see and navigate to Gateway, Branch A and Subsite 1 without error, although sites where they were only visitors they couldn’t make any changes, like creating new documents, etc..

The user Dina was a little different though. With no rights on Branch A, she couldn’t see it in the navigation:

Dina's view of the navigation in the web browser

She could, however, still go to Subsite 1 via it’s URL.

Dina can still visit Subsite 1

Note that the breadcrumb shows Branch A, but clicking on it gives:

Dina can't get to Branch A - Access denied

So far, so good. The browser interface behaves pretty much as one would expect.

Next, I wrote a console app that would, as each of the users, try the Web.GetWebCollection web service call on each of those sites. The results I got were:

Console App - initial results

Looking through the results, a pattern becomes pretty clear. Only sites where the user has Contribute rights work correctly, otherwise the result is an error. In other words, users with Read rights aren’t able to call the Web.GetWebCollection service, even though they can see sub-sites of the site in the web browser.


So what permission is doing this? Looking at Read and Contribute perms, I noticed the Browse Directories permission:

The Browse Directories permission
Hmm. All I can find on google says:

Enumerate files and folders in a Web site using an interface such as SharePoint Designer or Web-based Distributed Authoring and Versioning (Web DAV).

Well, it looks like something related to web services. I mean, SharePoint Designer must use the web services, right? Well, one way to find out – I added that right to the ‘Read’ permission level, and ran my application again:

Console App results with Browse Directories

This looks better – all calls have been successful, apart from Dina’s request of Branch A, which is also correct – she has no rights on that site!

So has this affected what users can see and do in the web interface?

Dina still can't get to Branch A in the web browser.

Well, no, would be the short answer.

So what is the Browse Directories permission? Well, damned if I know. All I can find on Google is the same text as above. I gather that it does somehow affect Spell-checking, but that still doesn’t tell me what it does.

After a fair bit of testing, I can’t see any other effects.

Browse Directories Permission and Webs.GetWebCollection strangeness

6 thoughts on “Browse Directories Permission and Webs.GetWebCollection strangeness

  1. Matt says:

    After enabling browse directories for the read permission group. I have noticed that if a user has rights to the root site that you are running the GetWebCollection web service you will get a list of all sub sites even if the user doesn’t have access to one of those sub sites. Is there a way to only show sub sites that the user has permission to?

  2. Yes – you simply need to make sure that they don’t have any rights to the subsites you don’t want them to see. This is the same situation as ‘Dina’ in the example above – for the middle layer of site’s she isn’t a Member or Vistor, and can’t see that site at all.

    You may find that your user has access under an ‘all authenticated users are visitors’ sort of a configuration.

  3. Wade says:

    I’ve encountered the same issue as Matt. Even after removing all permissions for a given user to a subsite, the GetWebCollection still returns subsites the user does not have any access to… This doesn’t seem right…

  4. Hmm. Yes, it doesn’t.

    However, I guess that my test is different to what you were looking at – I was trying to see if I could call the GetWebCollection service on the site the user has no permissions to. You’re trying to see if calling the parent site’s GetWebCollection service returns the site the user has no permission to.

    I can’t remember exactly, but I think I saw the same as you – that the call to the parent site would still return the child site – but that you couldn’t make the same GetWebCollection call on the restricted child site.

    And yes, it does seem to break the whole ‘security trimming’ thing a bit.

  5. Kristie says:


    I know this is out of the original topic, but did you guys figure out how to filter the “inaccessible” sites/libraries that both Matt and Wade were seeing? Aside from occurring in Webs.GetWebCollection, I’ve noticed this with Lists.GetListCollection and SiteData.EnumerateFolders. Worse, the web service will return a successful return code (HTTP 200) even if the user clearly does not have access to the site.

  6. Mahavir says:

    The worst thing is , Dina can see Site Action button now. You wuold not liketo show Site Action button to a user with read permissions.. right ? Then how to prevent showing the site action button to read permission user while adding “Browse Directories ” permission to their permission set for allowing web service method calls.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.