Suggest change to the group permissions

[Eschumac]

I'd like to suggest a change in the way group membership/permissions are handled. I'd like to see group membership and permissions be handled using bitwise operations.


I suggest taking the ibf_groups table and splitting into two tables. Leave ibf_groups with two colums.

g_title, g_group_mask


..Then take most of the the other columns in the present ipf_groups table and create another table like ipf_permissions with two columns

g_permission, g_permission_mask

And then change the mgroup column in the ibf_members to use a group mask.


Now, g_title in the ibf_groups table would be the same as it is today. The g_group_mask would be a number that would represent one of the bits of say a 32 bit number. For example if "validating" has a "g_group_mask" value of 1 it's bit representation would be "00000000000000000000000000000001". "Guest" could be "00000000000000000000000000000010" or 2. The next group would have to be 4 or "00000000000000000000000000000100" then 8 or "00000000000000000000000000001000" etc etc. Admin would always be "11111111111111111111111111111111" or "-1" (..or possibly 4294967295)


Now each item in the new ipf_permissions table gets a value that represents which group(s) have the permission. For example if we had a g_permission of g_use_search and we want only "members" and "admin" to be able to use the search we would first look at the goup mask for the groups "members". Let's say it's 8 or "00000000000000000000000000001000". We then set the g_permission_mask value for "g_use_search" to 8 or "00000000000000000000000000001000". Now if we want to see if the "members" group can use the search feature we can do a bitwise AND using the g_group_mask and the g_permission_mask to determine if the group can use search because:

00000000000000000000000000001000 g_group_mask

00000000000000000000000000001000 g_permission_mask

-------------------------------- AND

00000000000000000000000000001000 >0

..And because the admin group mask sets all bits the admin can also use search

11111111111111111111111111111111 g_group_mask

00000000000000000000000000001000 g_permission_mask

-------------------------------- AND

00000000000000000000000000001000 >0

On the negative test side if the group we were checking was guest (2) and they did not have permission to seach it would look like this:

00000000000000000000000000000010 g_group_mask

00000000000000000000000000001000 g_permission_mask

-------------------------------- AND

00000000000000000000000000000000 = 0 so user cannot search

You can see how this could make permissions etc very easy to code. Each time you add a new user group all you need to do to set it's permissions is run through the ipf_permissions g_permission_mask values and flip the bit that represents the group.

The other beauty of this approach is now you use the same approach for ibf_members "mgroup". Each user gets a 32 bit number that represents their group membership. You just flip the bits to id which groups they are in. Now when you want to know if the user can use search you can easily check by taking the users group mask and AND'ing it with the permission mask.

If user group mask AND the search feature mask > 0 then user can search.

The coolest thing about doing it this way is a person can be in more than one group very easily without having to to do a whole bunch of coding. This would also make the HTML logic very simple. Instead of having dozens of if statements for each group etc you can do a simple bitwise operation.

MySQL I believe supports bitwise operations on 64 bit numbers so I guess there is a limitation on possible groups of 64 if you use sql and bitwise operations.


Anyway, I hope I have explained this clearly enough, but if I haven't let me know and I'll give it another go. I think the use of bitwise operations would speed some things up and make coding group permissions a lot easier.

Cheers.

[Quillz]

It seems a bit complicated to me... And you may have already explained it, but what are the advantages of doing it this way?

[Eschumac]

haha..you said "bit" :rolleyes: ...anyway...

It's faster, in code and with MySQL. It's cleaner. It allows for multiple group membership. New permissions can be added very easily without adding new clumns to the db.... It may seem complicated, but it's really very simple.

[Quillz]

Sounds good.

[cthree]

It's not faster in code or with MySQL. It's faster and more efficient if you run your site in C on a micro-controller but if makes no practical sense for interpreted server script based, database driven applications. It also imposes a hard limit of 32 permissions and a nightmare for mod writers who risk using bits others also use. Disk controllers read your disk blocks at a time and you memory controller reads memory pages at a time. There is no practical benefit to this type of optimization on a dual Xeon with 2GB of RAM. You also can't index individual bits in a MySQL or any database field which means you need to do a full table scan everytime you want to select a range of records based on permissions.

Matt does know what he's doing. I've tried to improve his code and have succeed in a few places but mostly not. This type of optimization doesn't scale to this level unfortunately. I know what you're talking about being an embedded software engineer for the past 20 years I've done my share of bit-field operations. It just just doesn't work here and would prove a total disaster on many levels, database performance being the most significant.

Now stop looking at your binary LED watch ;)

[Eschumac]

If you wrap permissions up into a custom class users will not need to understand how the bitwise operations work. MySql supports a 64 bit bitwise operations. Do you know anyone with 64 groups in IPB? Even just 32? If you do how efficient is it?

Why would you need to index a mask for group permissions? I don't understand where this is required or needed.

Separating permissions from the group table is more efficient and scales better. Today if you want to add another permission to a group you add another column right. Not a good idea. It's better to simply add another row to the permissions table.

Think about how easy a permissions class would be. "Select * from Permissions". Then a method for validating the permission for any given user is as simple as AND'ing the permission's keyed pair value and the users group value. Simple.

The method is proven and is not my invention. This is a basic group permission pattern.

Prove to me that the current group permissions is more efficient and explain one way that the suggested method would be a "disaster". Show me I'm wrong. If you can show me I'm really really wrong. I'm open.

Forget about bitwise at the machine level for a second. Think architecture and scalability of the schema and design. Do you really want the group table growing wider and wider? Don't you want to add your own permissions? Don't you want your permissions to work without recoding anything?

You know, I didn't know there was a binary led watch...but they *are* cool. I like the blue one. :cool:

[Reeka Jean]

Do you know anyone with 64 groups in IPB? Even just 32?

I have 80 something permissions/user groups on my RPG forums.

As I run a Harry Potter community, and we have the four houses (and are up to 6 years in each house now), Aurors, Professors, Shopkeepers, Professor Assistants, Mediwitches, Ministry of Magic Employees, Deatheaters, etc etc etc.

Just so you know that *someone* does have that many permission/groups on their boards :D

And yes, they're all nessicary - as each group has certain forums they can/cannot get into, etc. So it's not just a bunch of excessive user groups/permission masks.

And actually, it's quite efficient on my boards. :)

[Eschumac]

Reeka_Jean,

So, if you have that many groups don't you think it would be more efficient to "build" group permissions by inheriting permissions from different groups? I have no idea about the Harry Potter stuff, but I assume you have redundant groups or the same group in each of the houses? Wouldn't it be getter to create a group for say Professors and a groups for one of the houses and then put a user in both groups to create their permissions? Basically, this is creating interfaces to other user groups. This could possibly cut your number of groups to 25%...but I really don't know how you have things set up. I would be curious though to take your current setup and use it as an example to prove things could be done in a easier way.

Using a method like that you could change permissions accross many virtual groups very easily. You can achieve quite a few more groups than 32 or 64 using combinations of group permissions. This is really more logical.


I think when you speak efficiency you are talking about organization rather than code.