Synergy
THE COMPANY . CONTACT
Home > Blog > MOSS Blog > Posts > Hiding the Sign In link for anonymous access to SharePoint web sites

 Posts

Hiding the Sign In link for anonymous access to SharePoint web sites
Gavin Adams

On a recent project of developing a public facing website using SharePoint 2007, we had a requirement to hide the “Sign In” link from the site for those accessing the site anonymously.

Firstly a bit of background on the SharePoint environment. It is configured with a single web application where the default zone has SSL access and windows auth for use by the content managers only. The web application has been extended to the internet zone for the http://www URL.

What we wanted was the sign-in link and the authoring controls, site action menu, etc to be visible for authenticated users but not visible for anonymous users.

Now I’d like to state that the following is not my idea just another one of those ideas which are spread across several blog posts. The following is an example of how I used this information in our implementation.

The solution is to use a SharePoint:SPSecurityTrimmedControl to only make enclosed code visible to authenticated users.

Here is the code snippet of what is in my master page including the SPSecurityTrimmedControl:-

   1: <!-- lock down authoring controls to only auth access -->
   2: <SharePoint:SPSecurityTrimmedControl PermissionsString="AddAndCustomizePages" runat="server">
   3:     <div id="sharepointAuthoring">
   4:       <div class="wrapper">
   5:                       <!--- --- --- Page Status Console --- --- --->
   6:                     <div style="height:0px;width:100%">
   7:                     <wssuc:DesignModeConsole id="IdDesignModeConsole" runat="server"/>
   8:                     </div>
   9:                     <!--- --- --- Site Actions Menu --- --- --->
  10:                     <span class="siteActionMenu">
  11:                     <PublishingSiteAction:SiteActionMenu runat="server"/>
  12:                     </span>
  13:                     <div class="sharepointLogin">
  14:                                     <!--- --- --- Authentication for Authors only --- --- --->
  15:                                     <span class="ms-globallinks">
  16:                                     <SharePoint:DelegateControl ControlId="GlobalSiteLink1" Scope="Farm" runat="server"/></span>
  17:                                     <span class="ms-globallinks">
  18:                                     <SharePoint:DelegateControl ControlId="GlobalSiteLink2" Scope="Farm" runat="server"/></span>
  19:                                     <span class="ms-globallinks">
  20:                                     <wssuc:Welcome id="explitLogout" runat="server"/></span>
  21:                     </div>
  22:                     <!--- --- --- Page Edit Toolbar --- --- --->
  23:                     <div class="console">
  24:                     <PublishingConsole:Console runat="server"/>
  25:                     </div>
  26:        </div>
  27:     </div>  <!-- end sharepointAuthoring -->
  28: </SharePoint:SPSecurityTrimmedControl>

 

The key element here is the PermissionsString="AddAndCustomizePages" property of the SPSecurityTrimmedControl.

This Permission levels and permissions page shows a list of all the permissions. If you refer to the Site Permissions table from the previous link we are looking for permission which do not have a read or limited access permission level. Two good candidates are either  AddAndCustomizePages or BrowseDirectories. These two have a minimum permission level of Design and Contribute respectively. As all the content managers for this site with either have a minimum of design or full control permission levels  it was ok to use the AddAndCustomizePages permission. If your authenticated users will only be a member of the ‘sitename Contribute’ group then you should use the BrowseDirectories permission.

 

There are some alternative solutions out there which require some custom coding or making a copy of the welcome.ascx. The advantage of the solution above is that no custom code is required, just modify your master page to suit.

I’d like to thank and reference the following blog posts for helping me solve this problem:-

I hope you find this example helpful in your SharePoint WCM efforts!

Gavin

Comments

There are no comments yet for this post.
Items on this list require content approval. Your submission will not appear in public views until approved by someone with proper rights. More information on content approval.

Title *


Body *


Posted By *


Attachments

Phone Number CLIENT LOGIN . CHANGE LOCALE . LIVE MEETING LOGIN . BLOG . PRIVACY POLICY . SITE MAP