PHP OOP - How to handle authorisation?

Question

I'm building a management system for an idea I have. I'm well versed in PHP (at least enough to do everything I need to do) but I'm not that experienced with using OOP. I use it as much as I can but a lot of the best practices I'm not familiar with so when I do things I worry I'm doing them in the wrong order.

For this project I have a class for the thing the user is managing, I need to check whether or not the user has permissions to manage it. I know how to check the permissions, my question is: where should I be doing it?

Should I be doing it outside the class, like so:

if user permissions are valid
initialize class
else return error

or should I be doing

initialize class
class checks permissions 
class returns error if permissions are invalid

I'm unsure which is the correct approach. On the one hand checking within the class seems the best based on what I know of OOP methodology, but then I also have the feeling that letting it get as far as initializing the class when permissions are unknown might be bad.

How should I be doing it? If there's any sort of article that covers this sort of thing a link would be greatly appreciated (I can't find anything through searches but I'm not 100% sure if I'm searching for the right thing as I know little of OOP)

Answer 1

It depends on what is your permissions model, and there is no "one correct way" to do it. It's a matter of approach. The important thing, is that whatever you choose, you use it consistently.

In my latest projects, I came across several different models. One of the most straightforward is a page-based permission, which is good if you do page-based flow, and use objects for support: you define at the top of the page who is supposed to access it and in case you can redirect. This is the simplest one, but can be very useful on specific applications.

If you, on the contrary, use objects to do your main flow, you should secure your object methods (rather than class instantiation). If you have a "save()" method, which can be called by specific users only, first thing when you enter that method, do your permissions check.

I am currently using an MVC pattern, and I have a Controller, which dispatches the actions to its children. Its only public method is execAction($params) and it will call actionAction($params) on itself, but first it will check permissions.

One important thing to remember is: never present actions on the UI that the user is not allowed to do (unless you are trying to force him to buy your "PRO version", that is) ;-)

Answer 2

I think best way to do is to have class of permissions. And then you can check before creating object or in object.

create permission class
if access then create class and set permission object
else error
// do action
if have permissions show something
else do not show something

Look how done in zend acl component

Answer 3

I have written a pretty solid and robust CMS system. Here's how I do it and I hope you can extrapolate some information on making your own solution.

• I have an index file, which loads an Admin class. Functionality in my CMS is modular (so containing in its own file and class).
• A module is loaded based on a $_GET parameter.
• Because the function to check the $_GET parameter and load the corresponding function is in my Admin class ($admin->pick_method()) and I also have a User object in my Admin class, I can first check the requested module is in the currently logged in user's permissions array.
• If the permissions check returns true, I load the module. If false, I display a friendly "unauthorized access" page.

Hope this helps.

Answer 4

Validating within the class generates a dependency between the class and the permissions authorisation which isn't good because you are tying together two potential disparate items. You can solve this by Inversion of Control (eg. dependency injection) or as I do by authorisation notifications using Emesary.

Validating outside of the class is possibly worse because there is a real danger that the authorisation check will be wrong or missed completely. It also creates the wrong sort of linking between objects as the object is not in control of itself.

If you are going to do it outside of the object when it is created then it is probably better to require the object to provide an interface such as IAuthorisable which can be verified by a seperate object.

e.g.

interface IAuthorisable
{
    public function getRequirements();
}

class Authorisation
{
     public static createObject($newObj)
     {
          if ( canDo( $newObj->getRequirements()) )
              return $newObj;
          return null;
     }
}

class Something implements IAuthorisable
{
     public function getRequirements()
     { 
          return SomeSortOfIdentifierOrSomething;
     }
}

$mySomething = Authorisation::createObject(new Something($p1, $p2), "

If $mySomething is null it isn't allowed. Obviously this needs extending and designing properly which is left as an exercise for the reader.

Answer 5

OO basics
If it makes sense to include it in the class. You could do it.
Does a Book class have an authenticate function? No, functions like download() and convertToPDF() make more sense.

My approach
I always try to find the route of the least resistance.

If there are 10 scripts/pages that talk to 1 class and 1 or 2 scripts needs authentication for certain actions i would build the authentication into those 1 or 2 scripts. (or put them in a subfolder with a .htpasswd)

But when you're using a MVC structure, everything is a class, so its become a question of deciding which class.
I tend to put the authentication rules in the Controllers classes and the authentication to database-logic in a User class.