1. Mix/Max of php and HTML code, which is pain in ASS to UI programmer, CSS guys.
2. Junk and vulnerable SQL statement, no way to make site secure.
3. Bunch of configuration variables and constants on config.php file.
4. Unmanaged structure of files, functions and classes.
5. Not proper modular structure which cause hard to maintenance application.
6. Personal interest of variable, function naming – lots of garbage and junk codes.
7. Writing and re-writing of code for same function within one projects and in multiple project.
8. No common standard and no central key. Different flow of each function/module, you never can say start and end when it comes to debugging.
9. And, I am seeing lot more others day by day…

So, on process of eliminating those stuffs, I keep enhancing that piece of code with feedback and direct involvement of some handful colleague, phpBricks is made.

I understand it is same pain for all programmers until you know such framework exists (I bet hundreds of such framework exists, just google it). So here, it is my privileges to share that piece of code, now so called phpBricks. I have uploaded demo copy, naming alpha release at SourceForge. I have been using it to build many commercial softwares. But I do not recommend you as this is alpha release and no sufficient resource will be found. If you want to use it, challenge the risk.

Update: RBAC model has been changed. This one is new model.

When RBAC is applied, an instance of RBAC is available in controller and views, but not in model classes. RBAC is not relevant in model because models are not supposed to contain any business logic. It is very much important to understand how each function is accessed to understand how RBAC determine authenticity. Each resource (or function) is identified with set of parameters, called CMA. Suppose you want to see list of users, that means calling index method of users. For that CMA parameter looks like (‘c’=>’user’, ‘m’=>’users’, ‘a’=>’index’).

In RBAC, permissions are assigned to roles not to users. Users inherit permission from their roles. So checking permission is done with combination of provided CMA parameters and roles. There is function called isPermission which takes 5 parameters. First three are CMA, fourth is primary_key (for advance business rule), and fifth is roles. Last two are optional.

For example, if you want to check that whether current loged in user has permission to see list of users or not:


if($this->Auth->isPermission('user','users','index'))
{
// code to list users
}
else
{
// sorry permission denied.
}
This works from view and controller.

Roles of user is collected at time of login and stored in session, which is available in $_SESSION['__userroles']. So if you don’t pass roles parameter, phpBricks suppose current user. Now your turn to think how do you check permission of a users who is not loged in.

———-

This blog is intended to alpha users of phpBricks. Thank you guys, you are source of energy. Thanks for suggestion, exceptions.

I have implemented lightweight form of RBAC (lightweight is my personal terminology). It’s lightweight because it exactly address need of web application. RBAC itself is very huge while implementing whole features, it’s like giant elephant. In phpBricks, RBAC is included in user component. As shown in figure bellow, it consists of Users, Roles, Permissions and Resource Registry (Operations).

• Users: Subject which access application. A user can have multiple roles e.g. Forum editor and CMS editor.
• Roles: Job title which consists list of operations (job). Roles can be two type, black list or white list (allow list or deny list)
• Permission: Indicate approval to access resources.
• Resource Registry: List of operations (action, also called method) which is grouped into component and module. Method represent actual operation or function where component and module are packges. phpBricks is smart that it collect all components, modules and methods, then build registry automatically so programmer don’t need to worry about accounting all these.

How to define?

From back-end when you access RBAC, it shows matrix of roles and resources (operations). Simply you can tick on check-box to allow or deny access. One important thing to remember is that role type. By default all operations are allowed in black-list role and all operations are denied in white-list roles. So by selecting operation under black-list role, you are banning access, but in white-list you are allowing.

How it works?

Resource is always identified by three parameters i.e. component, module and actions knows as CMA (fourth is optional i.e. primary key for advance business rule). So, whenever user try perform certain operation, based on CMA phpBricks authenticates.

What next?

Checking permission on realtime basis while access request is made, can cause performance to be slow. So, I am thinking permission caching technique.

Recommended reading:

Role-Based Access Control by David F. Ferraiolo (can be found it in Amazon)

Note:

In above text, following terminology may be confused while used interchangeably.

Operation=Function=Resource=Action=Method