Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Let's say I have a product that has different features, or different feature access depending on things (i.e Premium User, Beta, Demo, Logged-in User, etc..).

What's the best way to organize a system to where it's not a set of static checks (i.e a bunch of if statements, for example)?

The platform isn't important, I'm precisely asking for design principles / general design.

share|improve this question

closed as too broad by gnat, Bart van Ingen Schenau, GlenH7, Kilian Foth, MichaelT Mar 19 at 20:55

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Are the user types/roles static or do they change in application? –  Euphoric Jan 4 '13 at 14:30
    
@Euphoric They are fairly static. The base roles are completely static, but new ones might be added later on. –  Daniel Jan 4 '13 at 15:12
    
possible duplicate of How to efficiently protect part of an application with a license –  GlenH7 Mar 19 at 13:37
add comment

4 Answers 4

up vote 4 down vote accepted

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.

share|improve this answer
    
Yes, I'm representing a user as an object. –  Daniel Jan 4 '13 at 15:10
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.