Security trimmed top navigation links

I was asked to review a client environment yesterday to find out why the links in their top navigation bar were displaying for users that did not have permission to the particular sites.

Creating sites

It turns out that when sites were being created by the client on SharePoint Foundation 2010 they were being created without the ‘include on the top navigation bar’ check box ticked. As a result, the link was then not automatically added to the top navigation bar but instead later manually added and so was not security trimmed link.

Display this site on the top link bar of the parent site
Display this site on the top link bar of the parent site

It was then after removing permissions to the various sites that it became clear that users were able to see the top navigation bar link to the sites even though they did not have access.

Obviously, there are situations when users don’t have permissions to a site and you don’t want them to see that the site even exists. An example of this might be in an extranet scenario when you have third parties accessing project sites and you don’t want those third parties seeing the names of other project sites that may exist let alone the content…so how do we prevent this?

Identifying security trimmed links

By reviewing the URLs of the links in the top navigation bar I was able to identify whether the links were security trimmed or not. If the field for the URL is disabled then the link is security trimmed and most probably created when as the site was created.

Custom top navigation link that is not security trimmed
Custom top navigation link that is not security trimmed
Security trimmed top navigation link
Security trimmed top navigation link

Adding new security trimmed links

After identifying the problem, I then had to make the existing links security trimmed. I did this in two stages. The first was to make a note of the position of the link that needed to be replaced. I then deleted it from the top navigation bar using the ‘Top Link Bar’ site settings page (_layouts/topnav.aspx). The second stage was then to create the new security trimmed link by using the PowerShell code below.

Modify the $SPWeb and @(“Site Name”, “/sitename/default.aspx”) arguments as required and run the code for each of the top navigation bar links that need to be security trimmed. Remember the old link will need to be removed and the new one ordered as required.

Conclusion

It appears SharePoint, specifically SharePoint Foundation 2010 only honours security trimmed links in the top navigation when the links are created automatically as opposed to being created manually.

Note: this post specifically targets SharePoint 2010 Foundation which does not include the extended navigation that is included as part of the Publishing feature.

Hiding an empty rich text column in XSLT

This morning I was trying to create a new style in the itemstyle.xsl stylesheet to use within the content query web part (CQWP). I needed a custom style to display a list of announcements, some of which had content and others didn’t and this style was to improve this output.

The problem is that the ‘Body’ column of an announcement or more importantly the ‘rich text’ field type is never really empty. Even when the column genuinely empty and has no rich text content, a hidden HTML element (a div) exists and acts as a wrapper for any content. As a result, if you try and use a typical ‘if equals null’ statement to hide the rich text column it won’t work because of this hidden element.

Examples

An empty rich text column on SharePoint 2010 always has 37 characters as shown below.

Empty rich text column in SharePoint 2010
Empty rich text column in SharePoint 2010

With SharePoint 2007 the rich text column has 65 characters when empty, again as shown below.

Empty rich text column in SharePoint 2007
Empty rich text column in SharePoint 2007

Solution

The solution, in the end, was to use the string-length function to determine if the rich text column was longer than the standard 37 characters on SharePoint 2010 as identified above.

Working with Managed Paths in SharePoint using PowerShell

Quite a common requirement for implementations of SharePoint that I am involved in is to create new managed paths for a given web application.

While it is a simple task to perform via Central Administration, I inevitably turn to PowerShell to achieve this so that I can then include it as part of larger configuration or deployment scripts.

Define managed paths in Central Administration
Define managed paths in Central Administration

To manage managed paths in SharePoint we use the PowerShell Get-SPManagedPathNew-SPManagedPath and Remove-SPManagedPath cmdlets.

Reviewing existing managed paths

To get a list of all the managed paths for a given web application we use the Get-SPManagedPath cmdlet as shown below.

Get-SPManagedPaths PowerShell Cmdlet
Get-SPManagedPaths PowerShell Cmdlet

Creating a new explicit path

Explicit managed paths only allow one site collection to be created at a specific path. An example of this is the root site collection of a web application which has an explicit managed path of “/” (https://sharepoint.jcallaghan.com).

To add a new explicit managed path to a web application we use the New-SPManagedPath cmdlet and include the -Explicit parameter.

Adding a wildcard managed path

Wildcard managed paths allow one or more site collections to exist at a specified path. This is the same as the default ‘sites’ managed path that we should all be familiar with (https://sharepoint.jcallaghan.com/sites/projectxyz).

To add a wildcard managed path we run the command as we did for an explicit managed path however we don’t include the -Explicit parameter.

Custom managed paths added
Custom managed paths added

Removing an existing managed path

There may be times when you need to remove managed paths. This can be done by running the Remove-SPManagedPath cmdlet and specifying the name of the managed path to be removed and what web application to remove it from. When removing a managed path you will be prompted to confirm the removal action – this can be silenced by adding -confirm:$false to the command.

Conclusion

Using the SPManagedPath nouns in PowerShell we can get a list of existing managed paths, create explicit or wildcard managed paths and also remove existing managed paths for a given web application.

Adding a Yes, No, Cancel prompt to a PowerShell script

When I write PowerShell scripts, I often want to step through sections. This allows me to decided whether to proceed with parts of my script or not. I achieve this by using the ChoiceDescription class as demonstrated below.

More information about using prompts in PowerShell can be found in the following article and tip on Microsoft TechNet.

Clear the SharePoint Quick Launch using PowerShell

Today I had a requirement to remove all the headings and links from the quick launch navigation of hundreds of SharePoint sites. The sites were being provisioned as part of a PowerShell deployment script that was deleting the default list and libraries. Going through each of these sites manually was not an option – so I edited the deployment script to include a function to remove the headings for me.

SharePoint Quick Launch with Headings
SharePoint Quick Launch with Headings

I remembered doing something similar to this back on SharePoint 2007 but I didn’t have access to the previous script or project and instead had to research the subject for a while to find what I needed.

Solution

A post from Get-SPScripts supplied me with what I was after, although it was part of a much larger script. So I picked away at their code and made it into the following PowerShell function to re-use in other projects.

The above Remove-SPQuickLaunchLinks function will remove all headings and links from the SharePoint quick launch for a particular site.

Empty SharePoint Quick Launch
Empty SharePoint Quick Launch

Remember to review, rename and test this script before using it in a production environment.