Note: this list is kept only as a demonstration for CVSNotice. For the latest CVS notices, see the Xaraya and Postnuke sites
View Statistics - Next Notice - Previous NoticeDirectory filter : [ all ] / postnuke_official / html / modules / permissions / pnlang / zho [ view in CVS ]
Date | Directory [filter] | File(s) [view] | Author [filter] |
06 Aug 2002 11:43:59 | postnuke_official/html/modules/permissions/pnlang/zho | admin.php,NONE,1.1.2.1 manual.html,NONE,1.1.2.1 | Xiaoyu Huang |
working |
Update of /home/cvsroot/postnuke_official/html/modules/permissions/pnlang/zho In directory ns7.hostnuke.net:/tmp/cvs-serv12183 Added Files: Tag: PostNuke_71 admin.php manual.html Log Message: working --- NEW FILE: admin.php --- <?php // $Id: admin.php,v 1.1.2.1 2002/08/06 11:43:57 class007 Exp $ // // Original Author of file: Jim McDonald // Purpose of file: Language defines for NS-Permissions module // if (!defined('_DELETE')) { define('_DELETE','ɾ��'); } if (!defined('_EDIT')) { define('_EDIT','�༭'); } if (!defined('_PERMISSIONS')) { define('_PERMISSIONS','Ȩ��'); } define("_ALLGROUPS","�����"); define('_ALLREALMS','������'); // Realms defines until they get their own home define("_ALLUSERS","����û�"); define("_COMPONENT","Ԫ��"); define("_DOWN","����"); define('_GROUPPERMS','��'); define("_INSTANCE","ʵ��"); define('_MODIFYGROUPPERM','����Ȩ��'); define('_MODIFYPERM','��Ȩ��'); define('_MODIFYUSERPERM','���û�Ȩ��'); define('_NEWGROUPPERM','����Ȩ��'); define('_NEWPERM','�½�Ȩ��'); define('_NEWUSERPERM','���û�Ȩ��'); define("_PERMISSIONSNOAUTH","�û��Ȩ����Ȩ������"); define("_PERMLEVEL","Ȩ����"); define("_PERMOPS","���"); define('_REALM','����'); define("_SEQUENCE","���ȼ�"); define('_UNREGISTEREDGROUP','δע���û�'); define('_UNREGISTEREDUSER','δע���û�'); define("_UP","����"); define("_USER","�û�"); define("_VIEWGROUPPERMS","�鿴��Ȩ��"); define("_VIEWUSERPERMS","�鿴�û�Ȩ��"); ?> --- NEW FILE: manual.html --- <HTML> <HEAD> <TITLE>Permissions</TITLE> </HEAD> <BODY BGCOLOR=FFFFFF TEXT=000000> <FONT FACE=Verdana,Arial,Helvetica SIZE=2> <CENTER><B>Permissions</B></CENTER> <BR><BR> <H1>Introduction</H1> The PostNuke permissions system allows complete control over which content on the site is available to different users, and what they can do with it. It also allows the site to have multiple administrators, each responsible for their own area, and further subdivides all content into separate realms to allow for multiple sets of content on the same site but viewable by different users. <BR><BR> This help file covers the administration of the permissions system. <BR><BR> <HR> <B> Warning: Incorrect permissions could allow any user administrative access to your site. Please ensure that you have read and understood this document before attempting to set up your own permissions system. </B> <HR> <H2>Permission Attributes</H2> Each permission is compsed of a number of attributes. These attributes are explained in detail below. <H2>Realm</H2> A realm is an area of control for content. Most users will not need this, as they will only have a single realm. More information on realms can be found in the <A HREF="realms.html">realm manual</A>. <H2>User/Group</H2> This is the user or group that the permission applies to. More information on groups can be found in the <A HREF="groups.html">groups manual</A>. <H2>Component</H2> This is the component that you wish the permission to work against. The component takes the form of a triplet separated by the colon (:) symbol. There are three types of component <UL> <LI>System - System components take the form of "<I>system</I>:<I>area</I>:<I>instance</I>" where <I>area</I> and <I>instance</I> are currently reserved. <LI>Block - Block components take the form of "<I>type</I>:<I>instance</I>:<I>action</I>" where <I>type</I> is the block type ('Type' column on the blocks administration page) with 'block' appended to it, and <I>instance</I> and <I>action</I> are currently reserved. <LI>Module - Module components take the form of "<I>name</I>:<I>instance</I>:<I>area</I>" where <I>type</I> is the name of the module (e.g. "Web Links", "Downloads"), <I>instance</I> is currently reserved, and <I>area</I> is the are of the module affected. </UL> The component value is an anchored regular expression. To <A TARGET="_NEW" HREF="../admin.php?op=secshowinstanceinformation">see a list of currently registered componenets</A> you can click on the 'Component' or 'Instance' headings on the permissions view page. <HR> <B> Warning: Incorrect component values could allow any user administrative access to your site. Please ensure that you are familiar with regular expressions before attempting to set up your own permissions system. </B> <HR> <H2>Instance</H2> This is the instance of the component that you wish to permission to work against. The instance takes the form of a triplet separated by the colon (:) symbol. The instance values are component-dependent; a list of instance templates for all currently installed modules and blocks is available by clicking on the 'Instance' heading on the table. The instance value is an anchored regular expression. <H2>Level</H2> This is the level of authorisation provided. It can be one of the following: <UL> <LI>None - no access <LI>Overview - allowed an overview of the content <LI>Read - allowed to read the content <LI>Comment - allowed to comment on the content <LI>Moderate - allowed to moderate the content <LI>Edit - allowed to edit the content <LI>Add - allowed to add content <LI>Delete - allowed to delete content <LI>Admin - full access </UL> Ensure that the correct level is chosen to allow only as many permissions as are required. <H2>Ordering</H2> Ordering of permissions is very important. When checking for permissions the authorisation system will return the first matching permission that it finds, and this must be taken in to account when setting up a permissions sequence. <H2>User and Group Permissions</H2> User permissions are considered to explicitly override group permissions. If a group and a user permission are both found for an authorisation attempt, the permissions system will return the user permission. <H2>Examples</H2> The following are a number of examples showing the security system, with explanations. All of the examples use group permissions rather than user permissions; they allow easier configuration for larger sites with multiple users. User permissions follow the same method, but are explicit <H3>Initial Setup</H3> <IMG SRC="../../pnimages/perms01.png" ALT="Permissions example 01"> <BR><BR> This picture shows the initial permission settings that come with a new PostNuke install. A detailed explanation of each of the items follows: <UL> <LI> Allow those in group 'Admins' to access everything at permission level 'Admin'. <UL> <LI><B>Group</B> 'Admins'. This group should have all site administrators in it <LI><B>Component</B> '.*'. This matches any component <LI><B>Instance</B> '.*'. This matches any instance <LI><B>Level</B> 'Admin'. This allows the highest level of access </UL> <LI> Stop non-administrators from viewing the Administration entry in the main menu. <UL> <LI><B>Group</B> 'All groups'. This is a special group that includes every user on the site that is a member of a group, and also the unregistered (anonymous) user. Note that this group cannot have users added to it; it automatially picks up all users in the system when it runs. Note that it is a very good idea to ensure that all users are in at least one group on the system <LI><B>Component</B> 'Menublock::'. This matches anything with the component 'Menublock::', which are all of the blocks with type 'Menu' <LI><B>Instance</B> 'Main Menu:Administration:'. This will match for a menu block titled 'Main Menu' and a link titled 'Administration' <LI><B>Level</B> 'None'. This means that no access at all will be allowed; in the case of the menu this just means that the link will not be displayed </UL> <LI> Allow normal users to do anything on the system up to comment <UL> <LI><B>Group</B> 'Users'. This group should have all site users in it <LI><B>Component</B> '.*'. This matches any component <LI><B>Instance</B> '.*'. This matches any instance <LI><B>Level</B> 'Comment'. This allows access up to the level of commenting. Any attempts to do things beyond this will be refused. </UL> <LI> Stop unregistered users from seeing user-specific items in the main menu. <UL> <LI><B>Group</B> 'Unregistered'. This is a special group that corresponds only to users who are not logged in to the site. <LI><B>Component</B> 'Menublock::'. This matches anything with the component 'Menublock::', which are all of the blocks with type 'Menu' <LI><B>Instance</B> 'Main Menu:(My Account|Logout):'. This will match for a menu block titled 'Main Menu' and a link titled 'My Account' or 'Logout' <LI><B>Level</B> 'None'. This means that no access at all will be allowed; in the case of the menu this just means that the link will not be displayed </UL> <LI> Allow unregistered users to do anything on the system up to read <UL> <LI><B>Group</B> 'Unregistered'. This is a special group that corresponds only to users who are not logged in to the site. <LI><B>Component</B> '.*'. This matches any component <LI><B>Instance</B> '.*'. This matches any instance <LI><B>Level</B> 'Read'. This allows access up to the level of commenting. Any attempts to do things beyond this will be refused. </UL> </UL> <H3>Adding a Sub-administrator Group</H3> <IMG SRC="../../pnimages/perms02.png" ALT="Permissions example 02"> <BR><BR> This picture shows the permission settings after a new sub-administrator group has been added. The sub-administrator group is only allowed to administrate the 'Polls' and 'Web Links' areas of the site. <P> Note that the Web links area actually has two separate sub-sections for permissions. One is for categories, and the other is for the links themselves. We want this group to be able to work on both of these sub-sections. <P> This table only has one new entry. It is explained below. <UL> <LI>Allow subadmins access to polls and web links <UL> <LI><B>Group</B> 'Subadmins'. This is the group of subadministrators. Note that groups are created and populated through the <I>groups</I> administrative interface <LI><B>Component</B> '[(Polls::)|(Web lLnks:.*)]'. This is a relatively complex regular expression, that covers the component 'Polls::' and all components that start with 'Web Links:' <LI><B>Instance</B> '.*'. This matches any instance <LI><B>Level</B> 'Admin'. This allows the highest level of access </UL> </UL> <H3>Per-Group Settings</H3> <IMG SRC="../../pnimages/perms03.png" ALT="Permissions example 03"> <BR><BR> This picture shows the permission settings after a set of per-group settings have been added. Two new user groups, 'Technical people' and 'Design people', have been added and the administrator of the site wants to give them different polls that better reflect their knowledge. <P> This table has four new entries. They are explained below. <UL> <LI> Allow those in group 'Technical people' to comment on the poll about operating systems. <UL> <LI><B>Group</B> 'Technical people'. This is the group of people in the system that understand technical issues <LI><B>Component</B> 'Polls::'. This matches anything with the component 'Polls::' <LI><B>Instance</B> 'What Operating System Should This Site Run On\?::.*'. This is a very specific instance, and will only match to polls that have this question as the title. Note that the '?' in the title has to be escaped, as this is a regular expression.<BR> By looking at the instance schema for the polls it can be seen that an alternative way to express this would have been '.*:3', where '3' in this case is the unique ID of this poll. Using IDs is quicker and ensures uniqueness, but is a lot harder to understand when looking at the permissions system. The choice to use names or IDs is left to the individual site administrator It is also possible to use both title and ID if desired in this case the resultant instance would be 'What Operating System Should This Site Run On\?::3' <LI><B>Level</B> 'Comment'. This allows access up to the level of commenting. Any attempts to do things beyond this, such as editing or deleting the poll, will be refused </UL> <LI> Don't allow anyone else to comment on the poll about operating systems. <UL> <LI><B>Group</B> 'All groups'. This is a special group that includes every user on the site that is a member of a group, and also the unregistered (anonymous) user <LI><B>Component</B> 'Polls::'. This matches anything with the component 'Polls::' <LI><B>Instance</B> 'What Operating System Should This Site Run On\?::'. The specific instance for this poll, as has been explained above <LI><B>Level</B> 'None'. This means that no access at all will be allowed; in the case of the poll this just means that it will not be displayed </UL> <LI> Allow those in group 'Design people' to comment on the poll about the site design. <UL> <LI><B>Group</B> 'Design people'. This is the group of people in the system that understand design issues <LI><B>Component</B> 'Polls::'. This matches anything with the component 'Polls::' <LI><B>Instance</B> 'Should This Site Be Redesigned\?::.*'. This is a very specific instance, and will only match to polls that have this question as the title. Note that the '?' in the title has to be escaped, as this is a regular expression.<BR>See above for more information on specific instances. <LI><B>Level</B> 'Comment'. This allows access up to the level of commenting. Any attempts to do things beyond this, such as editing or deleting the poll, will be refused </UL> <LI> Don't allow anyone else to comment on the poll about the site design. <UL> <LI><B>Group</B> 'All groups'. This is a special group that includes every user on the site that is a member of a group, and also the unregistered (anonymous) user <LI><B>Component</B> 'Polls::'. This matches anything with the component 'Polls::' <LI><B>Instance</B> 'Should This Site Be Redesigned\?::.*'. The specific instance for this poll, as has been explained above <LI><B>Level</B> 'None'. This means that no access at all will be allowed; in the case of the poll this just means that it will not be displayed </UL> </UL> Note that any poll which does not explicitly fit the instance information is treated is ignored by these rules, so with this setup the normal poll will still show up in addition to the specialised polls. <H3>Admin Overrides</H3> <IMG SRC="../../pnimages/perms04.png" ALT="Permissions example 04"> <BR><BR> This picture shows how to fix a potential problem that results from the above changes. When an administrator logs on, he will get beseiged by polls - the two specialised ones and also the normal poll. Being an administrator, he probably doesn't even want to vote in them! <P> The solution to this problem is to block the administrator from seeing the polls. An obvious first attempt to do this would involve setting up a permissions entry for the administrators with a component of 'Polls::', an instance of '.*', an an access level of 'None'. However, this is <I>not</I> what is required. An entry like this would block administrative ccess to the polls altogether, so the administrators could no edit current polls, create new polls, or even access poll results. <P> What the administrator really wants to do is not to block access to the polls themselves, but to block access to the polls <I>blocks</I>. This means that the polls blocks are not displayed, but the polls themselves are still fully available through the administrative interface. <H3>Other Examples</H3> Future examples will be made available at a later date. </FONT> </BODY> </HTML>
View Statistics - Next Notice - Previous Notice
Visit Developer Site - Browse CVS Repository |
Syndicate via backend.rss (max. once per hour please) | Powered by CVSNotice 0.1.3 |