The Proxy design pattern may be an interesting starting point. One of the variations described in Design Patterns: Elements of Reusable Object-Oriented Software is called the protection proxy, which is designed for access control when different objects should have different access rights. The Decorator pattern may also be interesting, especially since a “protection proxy might be implemented exactly like a decorator”.

I’m assuming that you are representing your User as an object. A protection proxy to perform authentication or a decorator to add additional rights/privileges seems like a natural solution. But without knowing how you are representing your user and how it interacts with other aspects of your system, it’s hard to say anything more concrete.

I would start by creating a model, of couse. Create your business logic, data access, create some base classes, etc… Keep it loosly coupled for when you see that the design could be better.

There are two general approaches to solving this problem

• providing specific modules to enable features
• using a license key (or similar authorization mechanism) to control feature access

Based upon your mentioning of different features for beta users, you might want to consider organizing the features into separate modules. That will allow you to control which functionality is received without having to duplicate code paths (old path, new path) in the newer modules.

Using a license key to enable beta functionality would work if the functionality was brand new to the application.

A good example of this setup would be an Access Control List (ACL). Zend Framework (http://framework.zend.com/manual/2.0/en/modules/zend.permissions.acl.intro.html) has a permissions component implementing this type of setup. The general breakdown is that some models implement a Role interface and other models implement a Resource interface. A list (using a Registry pattern either through file configuration or in code) is created defining whether a Role can access a Resource and has a specific Privilege. I like to think of the privileges as an action list. There’s lots to explore in that component.

<?php 
    //$acl has been previously defined and loaded
    echo $acl->isAllowed('someUser', 'someResource', 'somePrivilege') ? 'yup' : 'nope'; ?>

    //$user is currently not logged in and has a 'guest' role
    if ($acl->isAllowed($user->getRole(), 'paidArticles', 'view') {
        //Show the paid articles, secrets and all that 
    } else {
        //Only show free articles
    }
    if ($acl->isAllowed($admin->getRole(), 'userList', 'delete') {
        //Allow $admin to delete users from the list 
    } else {
        //Perhaps log that someone is trying to access something they shouldn't
    }
?>

While I realize this is, or could turn into a complex set of If-Thens, at some point you’ll have to have a method to say, “If access is allowed, Then show X content/widget/etc”. If the permissions are fairly straightforward, it should remain simple. I think the main advantage here is it allows for a pretty basic isAllowed() and gives you a true/false based on however you have the roles, resources and actions setup. Past that it’s very flexible as to what you do as you query the ACL.