Specialized Groups


PostNuke initially defines two primary groups: Admins and Users. For many sites, you have no need to distinguish general users from one another, and these settings might be all you need. But, as your user base grows, you might find it useful to grant extra access to the regular visitors you know. If you are building a commercial site or business intranet, the importance of having tiered or segregated access is quickly apparent.

Two steps are necessary to create special permissions for your site. You must first lay out and detail exactly how the permissions should work, and then you must change the PostNuke settings to accommodate the desired structure.

Determining Access

Before you start making changes to your permissions tables, it's strongly recommended that you detail the access structure needed to give users access to the different site resources. Adding new permissions to the system is much easier and faster than making on-the-fly changes, especially on the live site. Moving users around to new groups is also timeconsuming when done and redone to account for previously missed issues.

Describe what you want to do with your site. What information is available to any visitor? What requires a login? Do some users have access to administrative features? Group your users into different types to conceptually assign them to resources. These types define the basic roles performed by members of the groups.

All of this information together is your site's permissions profile. You might need to read through the profile multiple times to be certain you have caught everything, but the completed document is invaluable. Not only does it reduce the time it takes to implement the settings, but it also is a great help should you need to reproduce your site from scratch at a later date.

Consider the permissions needed for a site centered on news. Suppose, for example, the news is concerned with a product called a Widgechip. The site distributes timely information to its visitors using the main news article system, posts editorials using the Sections module, has a frequently asked questions (FAQ) with essential information on the product, and includes a series of links to other websites with additional information on the Widgechip.

The site has a large number of visitors, and some have been selected to help maintain the currency of the content. Here is a listing of the different kinds of users for our example:

  • General Public Visitors with or without an account who are there to read the posted information.

  • Active Users Regular visitors who interact with the site by submitting information for possible addition and commenting on existing articles.

  • Reporters Users who post news stories without review. They are identical to regular users, but can also post their own news.

  • Support Staff Supporting staff who write, edit, and approve submissions to the FAQ.

  • Editors Content administrators who review and approve submitted content. They can also edit existing information.

  • Administrators Users with complete control over the website.

You can, of course, have as many groups as you want, but the preceding list provides a good example of common access types.

Browse to PostNuke's Groups module to create these groups. General Public is easily defined as the Unregistered users, so no group is required. The default Users group can be applied to the Active Users described in the preceding list. In Chapter 9, you created a group called Reporters. If you don't still have that group in your table, add it now. Create two additional groups called Support and Editors to complete the new additions.

The examples in Chapter 9 also included the creation of a number of demo user accounts. If you don't still have them available, create a few new accounts now. Assign at least one user to each group so that you can test the group's access. Be certain not to assign the same user account to multiple groups during this testing.

Now draw up a generalized table with the previous groups cross-referenced with the modules you expect to use. You don't need to be too specific about the permissions level, just use plain English to write out the main ideas.

Tip

Keep it simple. When drawing out permissions basics, describe resources no more detailed than full modules, and use simple access levels, such as Read, Add, Edit, Submit, and Admin.


You can see an example of this process in Table 16.1, which shows the main content modules, but nothing about the features of the modules. At this level, it's easiest to keep the layout simple to avoid confusion.

Table 16.1. Layout User Groups and Module Resources
 

NEWS

SECTIONS

WEB LINKS

FAQ

General Public

Read

Read

Read

Read

Active Users

Submit

Read

Submit

Submit

Reporters

Edit/Add

Read

Submit

Submit

Support Staff

Submit

Read

Submit

Edit/Add

Editors

Edit/Add

Edit/Add

Edit/Add

Edit/Add

Administrators

Admin

Admin

Admin

Admin


Now that the general access matrix is complete, it's time to expand the resources and get a little more specific. For example, the News module is actually a collection of multiple resources. You can read news, submit new articles, approve waiting articles, edit existing content, and administrate the entire module and its content. Different abilities can be separately described in permissions, and each can be associated with a user group for specific access; therefore, all of those actions can be considered resources.

For example, the News module itself includes the ability to read and comment on existing content. Article submissions are placed in a waiting queue through the separate Submit News module, and it takes the Add Story module to approve waiting news articles. Each module has different capabilities, and each one can be assigned the permissions level rights detailed in Chapter 9, but all of the modules are "News." Other modules can be completely self-contained but still have Components that can be defined separately.

Setting Permissions

Now, it's time to get detailed. Using your groups and resources matrix, the next step is to compare the general layout to the exact resource definitions available in PostNuke. To see exactly how to break out the resources, you need to review the Components and Instances defined for your site.

Tip

Remember that Components and Instances are like Classes and Objects in object-oriented programming. A Component is a feature of PostNuke, and an Instance is the live version of that feature as it appears in your site.


Table 16.2 lists the available Component and Instance options for a default install of PostNuke. As you add additional modules or remove unneeded core features, this list changes to reflect the new options. To generate this table dynamically, click either of the header links in the View Group Permissions table.

Table 16.2. Components and Their Instances

REGISTERED COMPONENT

INSTANCE TEMPLATE

Admin Messages:Messagesblock:

Block title::Message ID

Admin::

::

AvantGo::

::

Banners::Banner

Client name::Banner ID

Banners::Client

Client name::Client ID

Bannersblock::

Block title::

Bigblock::

Block title::

Blocks::

Block key:Block title:Block ID

Buttonblock::

Block title:Target URL:Image URL

Categoryblock::

Block title::

Censor::

:CensorMode:

Credits::

::

Downloads::Category

Category name::Category ID

Downloads::Item

File name::File ID

Ephemerids::

Ephemerid::Ephemerid ID

Ephemeridsblock::

Block title::

Example::

Example item name::Example item ID

Example:Firstblock:

Block title::

FAQ::

Category name::Category ID

fincludeblock::

Block title::

fxpblock::

Block title::

Groups::

Group Name::Group ID

HTMLblock::

Block title::

Languageblock::

Block title::

Languages::

::

legal::

::

Loginblock::

Block title::

Mailer::

::

MailUsers::

User name::User ID

Members_List::

::

Menublock::

Block title:Link name:

Messages::

Message title::Message ID

Modules::

::

Onlineblock::

Block title::

PHPblock::

Block title::

Pastblock::

Block title::

Permissions::

::

pnRender::

::

pnRender:pnRenderblock:

Block title::

Pollblock::

Block title::

Polls::

Poll title::Poll ID

Quotes::

Author name::Quote ID

Quotes:Quoteblock:

Block title::

Ratings::

Module name:Rating type:Item ID

Recommend us::

::

Referers::

::

Relatedblock::

Block title::

Reviews::

Review name::Review ID

RSSblock::

Block title::

Searchblock::

Block title::

Sections::Article

Article name:Section name:Article ID

Sections::Section

Section name::Section ID

Settings::

::

Stats::

::

Stories::Category

Category name::Category ID

Stories::Story

Author ID:Category name:Story ID

Storiesblock::

Block title::

Submit news::

::

Textblock::

Block title::

Top_List::

::

Topicblock::

Block title::

Topics::Related

Related name:Topic name:Topic ID

Topics::Topic

Topic name::Topic ID

typetool::

Module name::

Userblock::

Block title::

Users::

Uname::User ID

Web Links::Category

Category name::Category ID

Web Links::Link

Category name:Link name:Link ID

Weblinksblock::

Block title::

Xanthia::item

Xanthia item name::Xanthia item ID

Xanthia:LogoBlock:

Block title::

Xanthia:Moduleblock:

Block title::


The left column displays the physical Components, usually modules and blocks. The right column contains Instances of Components.

Browse to the Administration Menu for your site, and click the Permissions link. You are presented with the default group permissions table shown in Figure 16.1. There is a difference between resource security by obscurity and direct restriction of access. Note how Unregistered users are granted "None" access to the Submit News link in the Main Menu. That permission only restricts the link to Submit News, not the Submit News module itself. The final entry in the table restricts Unregistered users to Read access, and that is why visitors who have not logged in are not able to submit news.

Figure 16.1. Basic group access settings.


If you change the final entry in the table to increase Unregistered user access to the Comment level, anyone can use the Submit News module, even though the link in the Main Menu has been removed for those not logged in. Submit News is not a module you can simply "Read," so that level of access effectively prevents the use of Submit News. Granting Read rights to the entire site locks out special use modules that do more than just display content.

Refer back to Table 16.1 and compare the general layout of the access with the real Components and Instances in Table 16.2. You need to detail each resource separately to be certain the new permissions settings work as desired.

Let's work upward from the bottom of the Group Permissions table. The lowest access goes to the General Public group; this group is simple and only needs a global Read level of access. The current settings for Unregistered users work fine. It's also a good idea to leave the Main Menu restrictions for Unregistered users to prevent confusion.

Active Users are similarly taken care of using the Users' Comment setting, which allows submissions where possible and read-only access everywhere else.

Now, you need to add permissions for the Reporters group. As stated earlier, Reporters are basically like regular users, but with the additional ability to add their news stories. It's best to begin with the most general settings and get more specific with upper-access definitions. First create a new entry that makes Reporters exactly like Users. It should have these settings:

 Reporters     .*    .*     Comment 

and place the entry above the Users' line. This gives Reporters at least as much access as any user. Now add an additional Reporters entry above that one. The group only needs the Add rights to the news, so use this setting:

 Reporters    Stories::Story    .*    Add 

Granting access to a resource does not immediately mean the path to the given resource magically appears. The Main Menu does not include a link to the Add Story module, and because Reporters do not have Admin-level access, they cannot reach the page through the Administration Menu. To test the new setting, use this uniform resource locator (URL) that links directly to Add Story: http://www.yoursite.com/admin.php?module=NS-AddStory&op=main.

Tip

If you are not using the Main Menu block, you can place direct links like this directly into your theme.


A message at the top states: "Sorry, you have no admin authorization." This message is displayed in place of the story approval link. With the Add entry you created, Reporters can post their own articles, but they cannot approve the postings of others.

Browse to your Blocks Administration page to add a new link for Add Story. Edit the existing Main Menu block. In your new entry line, enter the following:

 Add Story    /admin.php?module=NS-AddStory&op=main    Add news story 

Tip

Check the Insert Blank After check box and submit the form without any other changes to make an extra line of space in the middle of the menu list. Then, you can add your new line and submit the form a second time to finish up.


Now return to the Permissions screen, and edit this default setting:

 All Groups    Menublock::    Main Menu:Administration:    None 

to look like this:

 All Groups    Menublock::    Main Menu:(Administration|Add Story):    None 

This change hides the Add Story link from all general users. You want the link to be visible to Reporters, so add a permissions entry above that which states this:

 Reporters    Menublock::    Main Menu:Add Story:    Read 

Now, Reporters can add their own news and see the link to perform the submission, but anyone else short of Admins do not see the link and do not have access to the form.

The Support group needs Admin-level access to the FAQ module, but otherwise, it's treated the same as Users. "Admin" is needed and not just "Add" because the Support group also approves submissions. First duplicate the User-style access for the Support group. It can be placed above or below the Reporters main lines; the groups are not related, so there is no hierarchy conflict.

 Support    .*    .*    Comment 

Tip

For a simpler Permissions table, try taking the multiple Group | .* | .* | Read permissions and combine them into one All Groups |.* |.* | Read enTRy. This way, all of your groups are treated as "Users" from the start.


Now add another line above the last addition that gives them administrative access to the FAQ:

 Support    FAQ::    .*    Admin 

You can test this access by logging in as one of your Support group test accounts and going to this URL: http://www.yoursite.com/admin.php?module=FAQ&op=main.

Browse to your Blocks Administration page again, and add a new link called "FAQ Admin." Edit the existing Main Menu block. In your new entry line, enter the following:

 FAQ Admin    /admin.php?module=FAQ&op=main    Administrate FAQ 

Back in the Permissions table, edit the Main Menu restriction line again and add the new link as follows:

 All Groups    Menublock::    Main Menu:(Administration|Add Story| FAQ Admin):    None 

Create a new permissions entry above the Menu restriction that states this:

 Support    Menublock::    Main Menu:FAQ Admin:    Read 

Now, just like Reporters, the Support group can see the FAQ Admin link, whereas other general users cannot.

The Editors need a slightly more complex set of entries. They can add, edit, and approve content, but they are not full-site administrators. First, grant their access.

Give Editors basic User access:

 Editors    .*    .*    Comment 

Then add Admin access for the main content areas:

 Editors    (Stories|Sections|Web Links| FAQ)::    .*    Admin 

Just as before, you can test this permission by going directly to the respective pages. Use the following links:

  • http://www.yoursite.com/admin.php?module=NS-AddStory&op=main

  • http://www.yoursite.com/admin.php?module=Sections&op=main

  • http://www.yoursite.com/admin.php?module=Web_Links&op=main

  • http://www.yoursite.com/admin.php?module=FAQ&op=main

Now, there is a problem with the preceding permissions entry, but you'll address it in a moment. First, you can make it easier for Editors to get to their Administrative pages. You could create multiple new entries in the Main Menu, and leverage the special links added for the other groups, but the easiest solution is to grant access to the Administration Menu.

The Administrative Menu page is populated dynamically; every icon and link is checked for access rights. Because the Editors group has Admin-level rights to multiple modules, it is a great deal easier to give the group one link to the Admin page and handle the access there. You can test this access by logging in as an Editor and going to http://www.yoursite.com/admin.php.

You should see three icons: Add Story, FAQ, and Sections. The missing Web Links icon is caused by a subtle difference in how the Web Links icon is displayed in the Administrative Menu. Granting access to "Web Links" makes the module itself available. To see the icon on the Administration page, you have to also grant access to "Web_Links." Edit your permission to add the icon access:

 Editors    (Stories|Sections|Web Links| Web_Links|FAQ)::    .*    Admin 

Now refresh the admin.php test link and you see the four icons in Figure 16.2. The same effect could be done for the Support group, but with only one module to access, it's a wasted click to have the group go to the Administration Menu before reaching the FAQ.

Figure 16.2. Customizing your Administration Menu.


Now add a permissions entry for the Editors' Main Menu. Anywhere above this line:

 All Groups    Menublock::    Main Menu:(Administration|Add Story|FAQ Admin):    None 

Add this entry:

 Editors    Menublock::    Main Menu:Administration:    Read 

And with that change, the example site permissions are complete. At this point, you should have a table that appears similar to the example shown in Figure 16.3:

Figure 16.3. Sample permissions table.


The access settings shown in the table were all done separately to make the changes for each group clearer, but it is also possible to simplify this table a bit. Note how the multiple groups all have the duplicate Comment access levels. The lines could all be combined into one entry for All Groups.

Table entries have precedence over entries below them, so the combined All Groups Comment entry needs to be at the very bottom of the table. That way, the restricted Unregistered entries overrides the User-level access. If you do not place the line at the very bottom, users who have not logged in will be able to post to the site.

This simplified version of the permissions is displayed in Figure 16.4.

Figure 16.4. Simplified permissions table entries.




    PostNuke Content Management
    PostNuke Content Management
    ISBN: 0672326868
    EAN: 2147483647
    Year: 2003
    Pages: 207
    Authors: Kevin Hatch

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net