Feature organization / authentication?

Question

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.

Are the user types/roles static or do they change in application? — Euphoric, Jan 04 '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 04 '13 at 15:12
possible duplicate of [How to efficiently protect part of an application with a license](http://programmers.stackexchange.com/questions/164608/how-to-efficiently-protect-part-of-an-application-with-a-license) — , Mar 19 '14 at 13:37

score 5 · Accepted Answer · answered Jan 04 '13 at 14:25

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.

Yes, I'm representing a user as an object. – Daniel Jan 04 '13 at 15:10 — Daniel, Jan 04 '13 at 15:10

score 1 · Answer 2 · answered Jan 04 '13 at 14:24

1

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.

answered Jan 04 '13 at 14:24

skeasor

111
4

score 1 · Answer 3 · answered Jan 04 '13 at 14:25

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.

score 1 · Answer 4 · answered Jan 05 '13 at 00:04

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.

Feature organization / authentication?

4 Answers4