Checking Channel User Rights

It is typically desirable to verify that the current user is allowed to perform an action rather than handling the access denied exception that occurs if we allow them to try to do something when they don't have sufficient rights.

Sufficient Rights

CMS help files outline the specific rights that a user must have to be considered sufficient for virtually any task. Since the goal of this chapter isn't about securing your site, this is left to other areas of the book. (See Chapter 17 for more information on how to set up user rights in Site Manager, and Chapters 19 and 20 for best practices on securing your CMS site.)

That said, most of the code in this part of the book assumes that the user logged in to CMS has sufficient rights to manipulate all the assets in the hierarchy. The easiest way to ensure that insufficient rights are not a problem while you are testing your site locally is to authenticate using the CMS administrator credentials or add the user that you log in to Windows with to the CMS Administrator group using Site Manger, and set IIS to use Integrated Windows authentication for your CMS site.

Alternatively, use the AuthenticateAsUser method of the CmsApplication Context, passing in the user name and password of the CMS administrator, rather than using the CmsHttpContext, as shown in most of the code examples. This way you can always dictate the user and Context PublishingMode. (See Chapter 24 for more information on using the AuthenticateAsUser method of CmsApplicationContext.)

Knowing what the user is allowed to do and not allowed to do can be helpful in dynamically generating navigation. It can be desirable to proactively leave off functionality that the current user isn't allowed to perform. It can also be desirable to visually indicate areas where the user is allowed to perform certain functions (such as by showing a certain icon in front of a link where the user is allowed to perform a given function). This can easily be accomplished using the user rights properties of the Channel object displayed in the following code.

The simple error handling in the code throughout these code samples isn't meant to be the model for how to handle CMS exceptions; there is an application code block from Microsoft on how to do exception handling in .NET. These functions also assume the presence of both a ListBox1 and a Label1 to provide visual feedback to the user, which certainly won't typically be normal, but it works for our purposes.

Replace the Button1_Click function of our Scratchpad template file (see the Scratchpad sidebar in Chapter 24 for details) with the following code:

 private void Button1_Click(object sender, System.EventArgs e) {   try   {     //1. Grab the current CMS Context     CmsHttpContext cmsContext = CmsHttpContext.Current;     //2. Populate the label with the name of the Channel, the     //   PublishingMode, and an anchor tag to the Update Mode URL     //   (if the user clicks this, the page will repost in CMS     //   Update Mode for the current Posting)     Label1.Text = "<b>Channel: </b>" +       cmsContext.Channel.Name.ToString() +       "<br><b>PublishingMode: </b>" + cmsContext.Mode.ToString() +       "<br><a href=" + cmsContext.Channel.UrlModeUpdate +       ">Link to Update Mode</a>";     //3. Populate the ListBox with values for the various     //   user rights     ListBox1.Items.Add( "CanDelete: " +       cmsContext.Channel.CanDelete.ToString()       );     ListBox1.Items.Add( "CanCreateChannels: " +       cmsContext.Channel.CanCreateChannels.ToString()       );     ListBox1.Items.Add( "CanCreatePostings: " +       cmsContext.Channel.CanCreatePostings.ToString()       );     ListBox1.Items.Add( "CanSetProperties: " +       cmsContext.Channel.CanSetProperties.ToString()       );   }   catch(Exception eError)   {     //4. Provide error feedback to the developer     Label1.Text = "<b>Error: </b>" + eError.Message.ToString();   } } 

Build the solution and then refresh the Scratchpad posting in Internet Explorer, or browse to it and click the Button. The page should reload and look similar to Figure 25-2.

Figure 25-2. Channel user rights

As you can probably surmise from the preceding example, CMS allows us to programmatically create, alter, and delete channels and create postings and connected postings in a referencing Channel object. What may not be self-evident is that the creation, alteration, and deletion of a channel do not have to be submitted or approved to take place. If the user has the authority to alter a channel and that change is committed, that change is live. These Channel properties will help us determine whether we could allow the current user access to this functionality.

The Boolean result of each property is strictly an indicator of the user's rights rather than the proper Context PublishingMode to perform the function. This way, we can provide a visual indication in the dynamic navigation of the user's ability or lack thereof to perform these functions regardless of the mode of the current Context. Therefore, just because one of these properties returns true, that doesn't automatically mean that any attempt to modify an object will succeed. To that end, it is always wise to place the verification that a user has sufficient rights and the actual modification within a .NET try/catch block.

Also, all the following Channel properties cannot be read for objects after they have been deleted and always return false for historical revisions of a Channel object.

A more representative coding example follows in the next main section of this chapter, Creating and Deleting Objects in a Channel.

CanDelete (Inherited from HierarchyItem)

The CanDelete property indicates whether the authenticated user can delete the referencing Channel object. This property will return true if the authenticated user has sufficient rights (see the Sufficient Rights sidebar) to delete the channel.

This property will return false if the authenticated user does not have sufficient rights or if the channel contains any children (channels or postings). In the preceding code example, CanDelete will always be false because we are asking if the user can delete the channel that this posting is in. Of course they can't; this channel has at least one child: the posting in which the code is running. Also, the CanDelete property will always return false if the referencing Channel object is the RootChannel. The RootChannel is a built-in entity and therefore can't be deleted by anyone.

CanCreateChannels

The CanCreateChannels property indicates whether the authenticated user can create channels within the referencing Channel object. This property will return true if the authenticated user has sufficient rights (see the Sufficient Rights sidebar) to create a channel within the referencing Channel object.

This property will return false if the authenticated user does not have sufficient rights.

CanCreatePostings

The CanCreatePostings property indicates whether the authenticated user can create postings within the referencing Channel object. This property will return true if the authenticated user has sufficient rights to create a posting within the referencing Channel object.

This property will return false if the authenticated user does not have sufficient rights.

CanSetProperties (Inherited from HierarchyItem)

The CanSetProperties property indicates whether the authenticated user can indeed alter the properties of the referencing channel object. This requires the same sufficient rights as creating and deleting a channel.

This property will return true if the authenticated user has sufficient rights and false if they do not have sufficient rights.