WitwickiTech.com

One of the projects I’m involved with is setting up an anonymous portal site. As part of the site we decided to include a “Contact Us” form which we implemented as a standard SharePoint list. To allow anonymous access to the site, we allowed users to access the Entire Web site via Permissions > Settings > Anonymous Access. It turns out that giving anonymous access to the entire web site only allows anonymous users to view items in a list. It does not give permission to add/edit/delete items in a list. In hindsight, the help text for the anonymous access setting does actually tell you this if you read it closely but it wasn’t obvious at first:

Anonymous Access
Specify what parts of your Web site (if any) anonymous users can access. If you select Entire Web site, anonymous users will be able to view all pages in your Web site and view all lists and items which inherit permissions from the Web site. If you select Lists and libraries, anonymous users will be able to view and change items only for those lists and libraries that have enabled permissions for anonymous users.

Because we do actually want anonymous users to have access to the entire site, we ended up having to break permission inheritance for the list and then explicitly allow anonymous users to Add/Edit items as well as View items (selected by default) using List Settings > Permissions for this list > Settings > Anonymous Access.

For Reference, the server environment is SharePoint 2007 Enterprise (MOSS) on Windows 2003 and SQL Server 2008 with WSS/MOSS SP2.

Stumbled across an interesting situation today. A site admin asked how to turn on security trimming for the top navigation links on a SharePoint site. She had created several subsites and didn’t want the top nav tabs displayed if the user didn’t have access. She knew it could be done because she had been on other sites where it worked.

My first thought was “It just works, there is no ‘turn it on’ option”. So I went to the site to take a look. Sure enough, two of the four tabs displayed even if the user didn’t have access to those subsites. So I did some investigating and it turns out that when manually creating top navigation headings (using the Publishing feature navigation screen), if you use the full URL to the subsite, security trimming does not occur while if you use the relative URL to the subsite, security trimming does work. That’s rather interesting behaviour and it makes me wonder what other effects can happen when using full URLs vs relative URLs.

For Reference, the server environment is SharePoint 2007 Enterprise (MOSS) on Windows 2003 and SQL Server 2005 with SP2 and the August 2009 CU. The client environment is Internet Explorer 7 on Windows XP with Office 2007.