Home

Your premium source for custom modification services for phpBB
  logo

HomeForumsBlogMOD ManagerFAQSearchRegisterLogin

Comments April 7, 2008

Designing the Forum Auth by Post Count MOD Part I: Private Permissions

Filed under: MOD Writing, phpBB — Dave Rathbun @ 9:53 pm CommentsComments (5) 

Our Story So Far…

Not too long ago I published that post in which I described an “auto group” MOD. I went on to explain that I don’t really think they’re a good idea, and I posted a couple of reasons why. The main reason was that this type of MOD adds too much overhead since it spends a lot of time checking things but doing nothing. That’s why I wrote the Forum Auth by Post Count MOD. This post talks more about the design of that MOD, and why I think it’s more appropriate for a busy board… or even a not-so-busy board for that matter.


Forum Permissions

In phpBB2 you are granted the ability to see a forum based on group membership. (You can do it by individual user as well, but please, just don’t. :) ) A forum is either public (viewable to all) or restricted in some way. Forums can be restricted to registered users which doesn’t come into play in this MOD. Forums can be restricted to Moderator or Administrator level users as well, which is part of the standard permission process and I’ll skip for now. The main focus of this idea was how to implement Private forums without doing a lot of manual permissions maintenance. For the rest of this post I will ignore the concept of individual user permissions and focus only on group permissions.

How Private Forums Work

When a forum requires private access to read a different set of rules is enforced. You have to be a member of a specific group. It does not matter what your user level might be. Think of it has having a VIP pass. If you don’t know the right people, you can’t get into the club. :)

So the first step is setting up a group in the Admin Control Panel (ACP). When I set this up, I make my group hidden as I think that makes the most sense. When a group is hidden nobody knows that it exists, so they can’t request membership. (An open group lets anyone in who asks to join, a closed group is visible but you have to be approved to join, and a hidden group is, well, hidden. :) ) Here’s what that looks like:

Private Groups

Notice that there are no fields on that screen related to post count? That means that membership in this group has to be driven by some other process.

The next screen shows the group permissions page. On this page I have a list of every forum that has been created. If the forum is private then there is an extra configuration option that allows me to configure whether the selected group has access to the private forum or not. That’s all there is to set this up.

Private Forums

Auto Group Functionality

Once the private group has been created and permissions granted, the next step is to put users into that group. This is where the Auto Group type of MOD comes in handy. It can manage that step for you. The benefit is that you don’t have to run a cron job or do any sort of manual maintenance. The cost is that you get a bunch of extra queries on a lot of pages. I’ve covered that already, so I’ll move on. :)

Authorizing by Post Count

An Auto Group MOD turns group membership into an event-driven process. When a post is processed (added or deleted) that event kicks of a process that adds or removes me from a group. When I get added to a private group, the private forum is now visible to me. I didn’t qualify for membership until I reached a certain post count.

Let me go back and restart the problem that I am trying to solve:

How can I grant authorization to view forums based on post count?

An auto-group MOD works by working with the standard phpBB2 group permissions, and I think that’s why those MODs were written in the first place. But they do require a board owner to set up private forums and groups for each forums and lots of rules.

What my MOD does instead is the exact opposite… it hides forums that would normally be visible. It hides them until you have reached the proper post level, as configured by the board owner. The Forum Auth by Post Count does not require private groups… in fact it does not require any groups to be created at all. It does not require private forums either. However, it does not override the existing phpBB2 authorization process. If a forum is configured so that it requires private permissions, this MOD will not bypass those restrictions. I think that’s an appropriate design. That way you can still have private forums on your board, as it does not reveal forums that are hidden.

It turns out that there are only a few places that you need to modify the core code to make that happen, and I’ll talk about that as well as the simple database alteration required in Part II of this series. 8)

5 Comments »

  1. Why don’t you like assigning permisisons on a per-user basis?

    Comment by Dog Cow — April 8, 2008 @ 2:58 pm

  2. That’s a fair question. :) Mainly it’ because it’s too hard to remember where they are. In most security applications you are advised to set up groups, and grant permissions to groups, and then assign users to groups. That way you only have one place to go to figure out an access rights issue. If you start granting things to individual users, then you have to check all of your individual users.

    Think about how phpBB works. When you click on a group, you can see the permissions for that group. You can use the user group control panel (groupcp.php) to see who is a member of that group. But without going into the database, can you easily determine which user has been granted permissions on a specific forum? Not really. :)

    I do everything with groups, and it’s much easier to manage. I think that’s a fairly standard practice. Do you use individual user permissions? If so, do you find them easy to track and manage?

    Comment by Dave Rathbun — April 8, 2008 @ 4:10 pm

  3. I’m actually in the process of writing a slightly different permissions system for my site, since it incoporates much more than forums and they all need authorizations. I was getting frustrated with each feature of my site having a different auths table and a different auths control panel, so I decided to write a “Zones”-based system instead. I have it explained in this post as well as the next one: http://macgui.com/forums/viewtopic.php?p=187939#187939

    However, I have some doubts about how I designed it. For example, it completely removes the groups functionality. My site, as of now, has no groups at all. I am now unsure of whether this was the right thing to do or not.

    The system works, but one of the features it is supposed to provide such as ‘global’ permissions are not functioning yet. One example of a global would be a user who can moderate all forums. I don’t have the part of the admin panel which allows me to actually aassign permissions to users finished yet, either.

    Comment by Dog Cow — April 8, 2008 @ 4:51 pm

  4. I am far from being a security expert, but every security system I have worked with has been primarily group-based. In fact, in some cases in order to assign an individual user some sort of permission you have to great a group and add that user… even if they’re the only user in that group. phpBB2 works best, in my opinion, with group rules rather than individual rules. I chatted with some folks on IRC to get an extremely basic overview (and by basic I mean about ten lines of conversation :lol: ) and phpBB3 is also slanted towards group roles.

    If every user has a unique set of permissions then user-based is the way to go. But I don’t think I have ever seen a system where literally every user has a set of permissions that are uniquely their own. Generally you create groups and assign permissions to groups. One group is called the “Everyone” group, and all users are in that group by default. An unregistered user is in the “Guest” group, and they have potentially different rights. And then there is the “Admin” group who owns the system. There’s your security system at its most basic level. :) Then you start adding new groups that have permissions or roles somewhere in between “Everyone” and “Admin” and those become your special groups.

    Typically the folks in these groups are the exceptions rather than the rule. Meaning the percentage of people with special permissions should be less than 5% of your total user population. Don’t ask me where that number came from, I pulled it out of thin air. :)

    I have to stop here or my anti-spam code is going to dump this comment to /dev/null :lol:

    Comment by Dave Rathbun — April 8, 2008 @ 5:51 pm

  5. Thank you for your explanations, they have helped me. I considered what you said about using groups, and I also took a look at ptirhiik’s auth system for phpBB2 as well as the phpBB3 auth system. Both would work wonderfully if my site was just a forum, but since it’s not, I have to implement my own system. This is why I am going with “Zones” which do not overlap. Each zone has its own sub-set of permissions, and then each zone has sub zones, these are the individual forums, gallery categories, calendars, etc. I just got global permissions working last night.

    The thing I am going to do now, based on your information, is to implement “Roles”, which both auth systems I mentioned implement, though ptirhiik calls his “presets” Now, remember each zone is separate, so each zone will have its own role, which is a predefined set of permissions. How trhis will work is I will set the permissions for a Zone, save it as a role, and then a role id will be attached to all permission entries for users which match the role’s permissions. Know that one user’s permissions entry takes up one row per zone. I will probably use an MD5 hash for matching. This will allow me to either: 1) have the system automatically find out what role the user is and set the role id, or 2) allow me to manually give users roles.

    With this, it is almost like groups, since I can view/sort users by role and zone, and I can see who has permissions assigned by a common role, and who is “out in left field” with permissions which don’t match a role.

    Comment by Dog Cow — April 9, 2008 @ 3:10 pm

RSS feed for comments on this post.

Leave a comment

Tags allowed in comments:
<a href="" title=""> <acronym title=""> <blockquote cite=""> <code> <strong> <em> <u> <sup> <sub> <strike>

Confirm submission by clicking only the marked checkbox:

     **         

Powered by WordPress