I had to decipher permissions for my application as well... I feel your pain!
Ok, lets see if I can remember this right:
JForum security is based on granting permissions(roles) to groups. There are two types of permissions (roles). One is a global permission. E.g. the perm_administration role grants group members the right to administer jforum.
The other is an "area specific" role. E.g. the perm_forum role grants (or denies) the right to access a specific forum. I say area, because there are roles that apply to forums and roles that apply to categories. (And there could be roles added that apply to other areas if needed.)
In the DB, the starting point for permissions is the jforum_roles table. This ties groups via the group_id to permissions (the name field). Also, in this table is a role_type column that is used by "global" option (0=deny/1=allow). Note that in 2.1.7 the role_type column has been dropped and the mechanism is generally: Allow if a global role record exists, deny if it doesn't.
To support "area" roles, there is a table named jforum_role_values. This links role (via the role_id key) to a permission defined role_value. This column is used to store the key of the "area" that the role applies to. E.g., with perm_forum, the role_value number is the forum_id of the forum you are granting/denying permission to. With perm_category, this is the category_id. In 2.1.6, the role_type column define deny(0) or access(1). In 2.1.7, the exist/not-exist rule is used.
That's how the data is stored. In order to use it, there is a very complex set of logic for loading and caching permissions. I won't go into that here... But the bottom line of this is that you can use the SecurityRepository object to get a PermissionControl object for a specific user, and use this to
test if the user has access or not. E.g.:
Not that the common permission names are stored in the SecurityConstants object.
So, where do you find out about what permissions are defined? The best place is to look at the permissions.xml config file. This is used to generate various admin screens and has the permission name, text to describe it, and if it's a global property (type=single) or area property (type=multiple). The area can be determined by the sql ref labels as well.
The final thing to note is that
you should look at/use the DAOGroupSecurity classes to set the permissions in the DB as this will update the SecurityRepository cache properly.
Hope this makes some sense, it's one of the most complex area of jForum....
[originally posted on jforum.net by monroe]
