Users, Roles, and Pages in DotNetNuke 5- An Extension

Understanding DotNetNuke roles and role groups

We just discussed how to add a user to your site. But are all users created equal? To understand how users are allowed to interact with the portal, we will need to take a look at what a role is and how it factors into the portal. There are plenty of real-world examples of roles we can look at. A police station, for example, can have sergeants, patrol cops, and detectives, and with each position come different responsibilities and privileges. In a police station, there are multiple people filling those positions (roles) with each of those belonging to the same position (role) sharing the same set of responsibilities and privileges.

Roles in our portal work the same way. Roles are set up to divide the responsibilities needed to run your portal, as well as to provide different content to different groups of users of your portal.

We want our portal to be easy for the administrators to manage. To do this, we will need to settle on the different user roles needed for our site. To determine this, we first need to decide on the different types of users who will access the portal. We will detail these user types in the following list:

  • Administrator: The administrators will have very high security. They will be able to modify, delete, or move anything on the site. They will be able to add and delete users and control all security settings. (This role comes built-in with DotNetNuke.) The default administrator account is created during the creation of the portal.
  • Home Page Admin: The home page admins will have the ability to modify only the information on the home page. They will be responsible for changing what users see when they first access your site. (We will be adding this role.)
  • Forum Admin: The forum moderators will have the ability to monitor and modify posts in your forum. They will have the ability to approve or disapprove messages posted. (We will be adding this role.)
  • Registered User: The registered users will be able to post messages in the forum and be able to access sections of the site set aside for registered users only. (This role comes built into DotNetNuke; however, we would need to provide the proper permissions to this role to perform the mentioned tasks.)
  • Unauthenticated User: The unauthenticated user is the most basic of all the user types. Any person browsing your site will fall under this category, until they have successfully logged in to the site. This user type will be able to browse certain sections of your portal, but will be restricted from posting in the forum and will not be allowed in the Registered Users Only section. (This role comes built into DotNetNuke; however, we would need to provide the proper permissions to this role to perform the mentioned tasks.)

Once you formulate the different user roles that will access the site, you will need to re strict users' access. For example, we only want the Home Page Admin to be able to edit items on the home page. To accomplish this, DotNetNuke uses role-based security. Role-based security allows you to give access to portions of your website based on what role the user belongs to. User-based security is also available per page or content section of the portal. However, the benefit of using a role-based security method is that you only have to define the access privileges for a role once. Then you just need to add users to that role and they will possess the privileges that the role defines. The following diagram gives you an idea of how this works:

Looking at the diagram, we notice two things:

  • Users can be assigned to more than one role
  • More than one user can be assigned to a single role

This gives us great flexibility when deciding on the authorization that users will possess in our portal.

To create the roles we have detailed, sign in with an administrator account, and select ADMIN | Security Roles on the main menu or click the Roles link in the Common Tasks section of the control panel. This is available on the top of every DNN page for authorized users. You might need to click the double down arrows on the top-right of the page to maximize the panel. The Security Roles page appears as shown in the following screenshot:

Notice that DotNetNuke comes with three roles already built into the system: the Administrators role (which we have been using), the Registered Users role, and the Subscribers role. Before we jump right into creating the role, let us first discuss the role group feature of DotNetNuke, as we will be using this feature when we create our roles.

A role group is a collection of roles used, mainly, in large sites with a large number of roles, as a way of managing the roles more effectively. For the site we are building, the benefit of using role groups will be minimal. However, in order to demonstrate how to use them, we will create one for our administrative roles.

While on the Security Roles page, click the Add New Role Group link located below the list of roles. This will present us with the Edit Role Group page containing two form fields.

Once these fields are filled out, click the Update link at the bottom of this page. A Filer By Role Group drop-down list should now be displayed above the list of roles on the Security Roles page. If you select the Administrative Roles group that we just created, two noticeable things happen on this page. Firstly, the list of roles become empty as no roles are currently assigned to this role group. Secondly, an edit (pencil) icon and a delete (red cross X) icon now appear next to the drop-down list. These icons can be used to update or remove any custom role groups that exist on the site. These red 'X' icons are standard icons used throughout DotNetNuke to represent the ability to delete/remove items.

Now that we have created our role group, we want to create the role for Home Page Admin. To do this, you again have two choices. Either select Add New Role from the dropdown in the upper left, or click on the Add New Role link. This will bring up the Edit Security Roles page, as shown in the next screenshot. We will use this page to create the Home Page Admin role that we need.

The Basic Settings shown in the screenshot are as follows:

  • Role Name: Make the name of your role short, but descriptive. The name should attempt to convey its purpose.
  • Description: Here you may detail the responsibilities of the role.
  • Role Group: Set this field to the Administrative Roles group that we created earlier.
  • Public Role: Checking this will give registered users of your site the ability to sign up for this role themselves. We will be creating a Newsletter role and will demonstrate how this works when it is created.
  • Auto Assignment: If this is checked, users will automatically be assigned to this role as soon as they register for your portal.

Do not check the Public Role and Auto Assignment checkboxes, unless you are sure. Checking these options would allow all users of the site to become members of the associated role, which would grant them the privileges assigned to the role.

As we want to decide who will be able to modify our home page, we will leave both of these unchecked. To save the settings, click on the Update link.

The Advanced Settings section allows you to set up a fee for certain security roles. We will not be configuring any of these settings for this particular exercise. However, we will briefly discuss how these settings can be used in Assigning security roles to users section.

Now to complete the roles that we will require for Coffee Connections, we will add two more security roles

The first role will be called Newsletter. We will be using this role to allow users to sign up for the newsletter we will be hosting at the Coffee Connections site. Set up the security role with the following information:

  • Role Name: Newsletter
  • Description: Allows users to register for the Coffee Connections Newsletter
  • Role Group: Leave this as the default < Global Roles > as it is not going to be used to grant administrative rights to its members
  • Public Role: Yes (checked)
  • Auto Assignment: No (unchecked)

Click on the Update link to save this role.

The second role will be called Forum Admin. We will be using this role to administer the forums at the Coffee Connections site. Set up the security role with the following information:

  • Role Name: Forum Admin
  • Description: Allows user to administer Coffee Connections Forum
  • Role Group: Administrative Roles
  • Public Role: No (unchecked)
  • Auto Assignment: No (unchecked)

Click on the Update link to save this role.

The security roles, by themselves, do not determine the security on your portal;you would need to assign the appropriate privileges to each role. As the diagram showed, users and roles work together to form the basis of the security in your site, based on the privileges assigned to the roles.

Assigning security roles to users

Security roles can be assigned to users by an administrator or any user given edit access to the User Accounts management section. Additionally, if Public Role is checked for any role, it can be assigned by the users themselves. To show you how users can sign up for security roles, log out as administrator and log in as our sample user, JonnyA.

When signed in as JonnyA, in order to modify your user information, click on the user name in the upper right-hand corner of the portal. This will bring you to the Manage Profile screen shown in the next screenshot. This is the same as the screen we looked at, when signed in as the administrator previously; however, this time it is displaying information associated with JonnyA, the currently logged-in user.

Note that when logged in as a regular user, there is no information on the right-hand side of the page. Only an administrator can see this information. A user can change his/her password by clicking on the Manage Password tab. They can manage their profile by clicking on the Manage Profile tab (refer to the following screenshot), or they can unregister from the site by clicking on the UnRegister link.

The Manage Services tab allows the user to manage the public security roles available to them. These are the roles for which we checked the Public Role checkbox. To subscribe to the role, click on the Subscribe link, as shown in the next screenshot:

After you have subscribed to a service, you can unsubscribe by clicking on the Unsubscribe link. As security roles, like Home Page Admin, allow the user to modify the portal, they should not be assigned in this manner. As the administrator of the site, we want the ability to decide who is assigned to this role. To do this, we will again need to sign off as JonnyA and sign in back as an administrator.

Once logged in, select ADMIN | Security Roles on the main menu or you may use the Roles link in the Common Tasks section of the control panel at the top of the page. Once there, click the pencil icon next to the Home Page Admin security role. Click on the Manage Users in this Role link that is located near the bottom of this screen. You will then be presented with the User Roles administration page, which is shown in the following screenshot:

To add a user to a role, select them from the User Name drop-down list. If you would like the role to expire after a specific date, you may enter a date in the Expiry Date textbox or click on the Calendar link to select a date from a calendar. In addition to expiring a user's membership to a role, you can also use the Effective Date to specify when to begin the user's membership in the role. For example, this feature may be useful for creating an employee's account before their hire date. When you are done, click on the Add User to Role link to add the role to the user.

You can add as many users to the role as you wish. To remove a role from a user, click on the delete icon 'X' (see the preceding screenshot) next to the user's name. Note that the delete icon may not be visible if a user cannot be removed from a particular role. For example, the portal admin account cannot be removed from the administrator's role.

If the Send Notification checkbox is checked, then the portal will send an e-mail notification to the users when they are added or removed from the role.

Up to this point, we have added security roles, and added users to roles, both as an administrator and by allowing users to add themselves through membership services. However, the security role privileges (or authorizations) still need to be set. To do this, we will introduce you to the page (also referred to as a tab) architecture of DotNetNuke. In the process, we will show you how to add security roles to sections of our portal.

Role advanced settings

Depending on what you are offering on your portal, you can ask for a fee for a user to register for your portal or just to access particular sections. To enable this feature, the Payment Processor section of the Site Settings page must be configured. To do this, make sure you are logged in as an administrator, and click on the Site Settings item under the ADMIN menu.

On the Site Settings page, expand the Advanced Settings section and then expand the Payment Settings section. Here you will find the following fields:

  • Currency: This will determine the currency used when users make payments through the site.
  • Payment Processor: This is the merchant gateway used to process payments. By default the only choice is PayPal.
  • Processor UserId: The username, user ID, or e-mail address used to log in to the payment processor. PayPal currently uses an e-mail address.
  • Processor Password: The password associated with the user ID specified in the previous field.

Once this is configured, navigate back to the Security Roles page we used earlier to create our custom roles. One way to do this is to click on the Roles link in the Common Tasks section of the control panel. Choose a role to modify to require a fee, and click on the edit (pencil) icon next to that role. Now on the Edit Security Roles page, expand the Advanced Settings section. The following fields will be displayed:

  • Service Fee: The fee charged to users in this role.
  • Billing Period: Two fields are associated with this setting. The drop-down list allows you to select from a list of time periods, such as month or year. The textbox is used to specify the number of such periods, for example, 2 months.
  • Trial Fee: This field works like the Service Fee, but can be used to offer a trial at a different rate, allowing for a free trial.
  • Trial Period: This field works like the Billing Period, but can be used to offer a shorter trial period.
  • RSVP Code: This code can be shared among roles to allow users to subscribe to multiple roles using a single code.
  • RSVP Link: The link provided here can be sent to users to automatically add them to the associated role(s).
  • Icon: A specific icon can be provided for each role.

These features allow for several useful scenarios for membership-based sites. Allowing a trial period can be especially helpful when trying to promote the site. When using the RSVP Link, be aware that the user using the link must already be logged in to the site or log in to the site from the link. This can be problematic, due to the fact that the page does not inform the user that they need to log in if they have not.

To work around this limitation, you can create a page that shows a message to unauthenticated users informing them to log in to activate their membership. Then modify the link to the new page to include?rsvp=[RSVPCODE] where [RSVPCODE] is replaced with the code entered in the RSVP Code field. This work around is not necessary, but it does make the experience a little more user friendly.

Understanding DotNetNuke pages and tabIDs

As we have been navigating through different pages, you may have noticed that the page address changed; however, this is a bit of an illusion. While browsing through the pages, the page name displayed in the address bar closely resembles the title of the page. For example, while on the home page, the page name in the address bar is Home.aspx. This is because DotNetNuke uses dynamic page generation to render the correct information for each page. In a nutshell, the DotNetNuke framework uses the page name displayed in the address bar to determine which information to display.

You will see that some of the screenshots in this article, as well as other pages on your DotNetNuke portal refer to something called a tab. In previous versions of DotNetNuke the word "tab" was used instead of the word "page". I am sure that in time, all of these references will be changed inside the portal. Until then be aware that the words "tab" and "page" are interchangeable; for instance, the host pages still use the word "tab".

In traditional web applications, pages are created in an application such as FrontPage, Dreamweaver, or Visual Studio.NET. The designer decides where to place the text, inserts images, saves the page, and then posts it on the website. Navigating the traditional web application takes you from one "physical" page to another "physical" page. The following diagram is an example of how a traditional web application would be constructed:

In the DotNetNuke web portal, there is only one "physical" page used in the application. Instead of placing the information directly on the page, DotNetNuke holds the information for each page in the database. When a page is requested on a DNN portal, the application looks in the database to determine what information should be on the page and displays it on Default.aspx. The database knows what information to pull from the database by looking at the page name in the URL (for example, http://localhost/DotNetNuke/Home.aspx). I can hear you saying "incredible" and I completely agree. This is one of the great features provided by DotNetNuke. The process of determining what page to display based on the page name is handled by the human friendly URL provider. The following image shows an example of how the DotNetNuke web application is constructed, in relation to the traditional web application:

When users navigate to different items on the menu, they will see different information and will be presented with the illusion of multiple physical pages.

When you create new pages in DotNetNuke, you are not only creating the page information for the database, but also building the navigation menu for your site.

To understand the pages and menu structure better, we will create some new pages. To create a new page, we first need to log in as an administrator. When you do so, you will see the Page Functions pane at the top of your portal, as shown in the following screenshot:

In DotNetNuke 5.2 and later versions, you can grant access to security roles other than administrators to manage the pages on the portal, by placing the Tabs module on a page and grant users or roles access to it.

To add a page, click on the Add link on the left-hand side of the pane. We will be adding a page that will hold our Coffee House search engine, as well as a page that will eventually hold our forums. This Edit Page screen is broken up into three different sections, Basic Settings, Copy Page, and Advanced Settings.

We will start with the Basic Settings, which appears as shown in the following screenshot:

This is where we enter the following information to set up our page:

  • Page Name: This is the name that will show up on the menu. You should keep this name short, in order to save space on the menu.
  • Page Title: This is used to display the name of the page on the Internet Explorer title bar. This can be more descriptive than the page name. If this field is left blank, it will automatically be filled in with the value entered into the Page Name field.
  • Description: Enter a short description of what the page will be used for. The values in this field are used to populate the meta description tag that is used by search engines.
  • Keywords: This section is used to enter keywords that will be picked up by search engines.
  • Parent Page: As we discussed earlier, this information not only creates a page dynamically, but is also used to create your site menu. If you would like this page to be positioned under another page in the menu, then select the parent page from the drop-down list.
  • Insert Page: This selection determines where the page will be placed in the site navigation menu. The page can be inserted Before or After the Parent Page selected. The Add to End selection inserts the page as the last page in the menu.
  • Template Folder: This drop-down list lets you specify a folder to look for page templates.
  • Page Template: Page templates allow you to save the configuration of a page as a template. Then it can be used to create copies of the saved page by selecting the template when you create a new page. The Default template is provided by DotNetNuke and creates a page with a single HTML module already added to the page.
  • Include In Menu?: Uncheck this option to prevent the page from being displayed in the site navigation menu. Administrators, or users granted access to the Tabs module, will be able to see and modify hidden pages using the Tabs module or the Pages administration page. This can be useful if you would like to navigate to a page in a non-traditional way. For example, you can add a link to specific page using the Links module.
  • Permissions/View Page: Roles or users that are selected in this column will have the ability to view the page. This means that only those roles or users who have been checked will be able to see this page. If you are not in one of these roles, or your account is not specified, then you will not see the page. This can be used to restrict portions of your portal to certain groups or people. Clicking the permission a second time will display a red circle with a 'X' to explicitly deny the permission for the associated role or user.
  • Permissions/Edit Page: Roles or users that are selected in this column will have the ability to administer this page. This means that a user who belongs to any of the roles or users checked will have the ability to edit, modify, and delete information on this page. Remember these privileges apply to this page only. Clicking the permission a second time will display a red circle with a 'X' to explicitly deny the permission for the associated role or user.

Under the Copy Page section (refer to the next screenshot), you can select whether you would like to copy information from an existing page to create a new page.

To copy a page, select the page you would like to copy from the drop-down list. This results in a list of the modules on that page. You can select whether to copy each module by checking the checkbox on the left-hand side of the list. You also have the ability to rename the module, or change its title, by changing the text in the textbox. Finally, there are three options that relate to how the module is copied.

  • New: An empty module of the same type is created on the new page
  • Copy: An exact duplicate of the module is created on the new page (with a new ID)
  • Reference: A new instance of the module is created on the new page (with the same ID)

Initially, there appears to be no difference between the last two options as the resulting modules look the same. However, a copied module is not related in any way to the original module, so modifying the contents of a copied module does not change the original module. On the other hand, a referenced module is the samecontent displayed on a different page. Changing the content in a referenced module will affect both pages. DotNetNuke's module structure is very flexible, as we will see later.

The Advanced Settings section, as shown in the next screenshot, is divided into three subsections, Appearance, Cache Settings, and Other Settings.

The Icon drop-down menu allows you to add an icon next to the page name on the menu. You can see an example of this in the ADMIN menu as shown:

In the ADMIN menu, the admin page is the parent for Security Roles, as well as the others in the list. As you can see, if you use an icon, it will be placed on the left of the page name.

The Large icon drop-down list works similar to the Icon selection; however, instead of being displayed in the menu, it will be displayed in the container, as long as the container supports an icon.

The next portion of the Page Functions pane (see the next screenshot) deals with skinning. For now, we will leave < User Portal Default > selected. A full discussion on skinning is beyond the scope of this section; however, a brief description is definitely in order.

The terms skin and container are used throughout the DotNetNuke platform to describe portions of the "look and feel" of a site. Specifically, skin refers to the overall design (that is, layout, color palette, and so on.) of the site. A container is the portion of the design that contains or surrounds a module. The settings in this section allow the skin for the particular page to be set, as well as the default container for each module on the page.

Checking the Disabled checkbox (shown in the next screenshot) will allow a page to show up on the menu, but will not allow the page to be shown. A disabled page is used only as a parent page to allow you to navigate to the other pages beneath it. If you click on the menu item that is disabled, nothing will happen and you will remain on the current page.

Finally, at the end of this section, you have the ability to add a Refresh Interval and Page Header Tags. The Refresh Interval will automatically refresh this page after the specified time (in seconds). The Page Header Tags section allows you to interject meta tags into the header of this page. This is helpful; as DNN builds pages dynamicity, and you can use this to modify the header. We will be leaving these sections blank.

In the Others Settings section (shown in the preceding screenshot), you can administer when your page appears and how its menu item is utilized.

  • Secure?: This determines if the page should be forced to use SSL and will only be available if the SSL Enabled checkbox has been checked in the Site Settings for the portal.
  • Site Map Priority: The number entered here ranges from 0.0 to 1.0 and helps the search engine crawlers determine the importance of the given page compared to other pages on the site.
  • Start Date: This will determine the start date that your page will become visible to your users.
  • End Date: This will determine the end date that your page will no longer be visible to your users.
  • Link Url: If you would like a menu item to link to information that already exists on your site, then you can fill in the Link Url information. You can link to an external resource (a page or file on another site), a page on your site (an existing "physical" page on your website), or a file on your site. This can be used to incorporate existing ASP or HTML files that you may already have.

To save your settings for this page, click on the Update link. When it is complete, you will see your new page on the menu bar. Therefore, when you build a page you are creating both a page to add content to and also an item for your menu.

Administering pages

You have now seen how you can create a page using the Page Functions pane. Next you will see how to work with all of your pages to build your menus in a straightforward manner. To get to the Pages administration section, select ADMIN | Pages on the main menu. Your screen will appear similar to the following screenshot:

By using the icons on the module displayed here, you will be able to create a new page, edit or view an existing page, or modify where the link to the page appears on your menu. To test this, highlight the Coffee House Search menu item and click on the View Selected Page icon (magnifying glass). This will bring us back to the page that we just created. Notice that the page is separated into five distinct panes. The TopPane, LeftPane, ContentPane, RightPane, and BottomPane (you may need to click on the Layout radio button above the Page Functions pane if the panes are not visible).

Take some time to try out the functionality on this page and get comfortable with how you can edit, move, and modify your pages.

You will notice that the ADMIN menu items appear on this page with the other pages on your site. You are able to modify those menu items as you would on any other page. The Manage Host Tabs checkbox will change the module to allow you to manage the HOST menu items. Please be cautious when modifying the ADMIN and HOST menu items. If you remove items from these menus, then you will have to recreate these pages yourself. This may prove to be a challenge is some cases.


In this article, we covered the concepts of users, roles, and pages.

If you have read this article you may be interested to view :

You've been reading an excerpt of:

Building Websites with DotNetNuke 5

Explore Title