• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

going bonkers on role-permissions!

 
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Rafael and gang,

Can anyone plz point me to a place where we have any sort of documentation of the permissioning in the system? I'm working on 2.1.6 and permissioning is just making me go nuts

Worst case scenario, can anyone help me understand the process of how permissions are assigned to roles?

there are things like roleNames, roleValues, roleType: any one can help me define the correlation.

any help is highly appreciated. thnx in advance.
[originally posted on jforum.net by pankajvermani]
 
Migrated From Jforum.net
Ranch Hand
Posts: 17424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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]
 
Everyone is a villain in someone else's story. Especially this devious tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic