SharePoint Global Navigation Sometimes Ignores Target Audience Settings

Home » SharePoint Administration » SharePoint Global Navigation Sometimes Ignores Target Audience Settings

SharePoint Global Navigation Sometimes Ignores Target Audience Settings

Posted on

I recently came across a curious scenario when using target audiences with SharePoint 2010 global navigation. I began with a common enough requirement – create a static menu structure in which certain links would be visible only to members of specific SharePoint security groups (no Active Directory in this particular environment). The basic hierarchy looked something like the following:

Root Node [Members]
— Publishing Page 1 [Custom SP Group 1]
— Publishing Page 2 [Custom SP Group 1]
— Layouts Page [Custom SP Group 2]
— External Link [Custom SP Group 3]

In reality it was a bit more complex than that but not by much. At first, it all worked as expected. But then I noticed that the Layouts Page and External Link were showing up no matter what group a user was in. That seemed odd but not catastrophic – anonymous users still couldn’t see the root node so all it needed was a little tweaking to get the groups right. That’s where the fun began. The audience setting for each node mapped to only one SP group and there was no cross-membership in any of the groups. In theory, members of Group 3 shouldn’t see anything but the last link; in practice, they were presented with the Layouts Page node and the External Link node but NOT the Publishing Page nodes. No matter what I did, the Layouts and External nodes always showed up.

About this time I realized that the Root node would have to changed as it wouldn’t work for users on IOS (iPhone, iPad) – Safari on the touch platform won’t allow the drop-down menu to expand like clicking on the arrow with a mouse would. It always navigates the user to the root node link. No problem, I had already dealt with this on the other root nodes, so I simply removed the link from the Root node, left the target audience set to Members, and inserted a child node (thus, when the root node was touched or clicked, it would simply expand the child nodes instead of navigating anywhere). The menu structure then became:

Root Node [Members] (empty link field)
— Home Page [Members]
— Publishing Page 1 [Custom SP Group 1]
— Publishing Page 2 [Custom SP Group 1]
— Layouts Page [Custom SP Group 2]
— External Link [Custom SP Group 3]

Oops, now I really had a problem. As soon as I removed the hyperlink value from the root node, the root element, layouts node and external node all became visible to anonymous users! Mucho bad mojo, there – no way would the customer allow non-authenticated users to see a root node that should only be available to authenticated users. I put a random value into the hyperlink field to try and hide to root menu item but nothing worked until I put in a reference to an actual SharePoint object (web, page, list item, etc.) – so long as that object wasn’t an application page in the /_layouts directory. Ok, serious head-scratching time. This didn’t make any sense at all whatsoever. Why should SharePoint care whether or not the node links to an SP object or www.anyoldwebsite.com?

My immediate suspicion was that somehow the external and layouts links were falling through the security trimming logic in some way. However, Audiences don’t work the same way as actual security groups. The only check that’s performed on an audience is whether or not the user is a member of the specified group not whether that group actually has permissions on the target object – that’s a completely different process. Had it been a security trimming issue, anonymous users wouldn’t have been able to see the Layouts Page link as the lockdown feature was enabled on the site. Something else was going on behind the scenes but what could it be.

So, being the curious developer type that I am, I fired up ILSpy, turned on the Developer Dashboard and went to work tracking down this little gem of undocumented functionality. After stumbling along several blind alleys, following umpteen dead-end stub methods (really, do we need a bunch of classes that do nothing but return false every time they’re called?), and twisting my brain around convoluted inline nested IF statements, I finally discovered the answer. Turns out that there’s a nice little method in the Publishing namespace called CreateObjectFromID that is responsible for taking a reference to a cached node object in a site map data source and returning an object of a specific node type. Unfortunately, there are only three allowable node types – Web, Page or ListItem (with the default in the switch statement being ListItem). This means that a link must point to something that can be converted to one of these three types. Nice – not even a catch to allow for generic or non-SP objects.

As if that little coding blunder wasn’t enough, the convoluted logic in the GetNavigationChildren method of PortalSiteMapNode allows a null object (which is the result of not matching one of the three allowable types) to be displayed – the exact opposite of how I would think it should work. This may not be security trimming but it’s awfully darn close, at least in spirit – I would have fallen back to hiding anything I didn’t know how to deal with (null) instead of allowing it to pass through. So, the net result is this brilliant bit of logic:

  1. If the node includes a link to something that cannot be converted to a Web, Page or ListItem, audience targeting will be ignored.
  2. If the root node does not satisfy #1 then the root and the child nodes will be hidden.
  3. If a child node satisfies #1 it will be displayed only IF the root node also satisfies #1.

The only way to circumvent this functionality is to make sure that all static links in the navigation settings point to valid SharePoint objects that are either a Web (site collection root or subsite), Page (publishing, web part, wiki, etc.) or a list item if you intend to use target audiences to restrict the display of individual nodes.

And there you have it. Another afternoon wasted in the dark back alleys of SharePoint. Aren’t you glad I beat my head against the wall so you don’t have to?