NYCPHP Meetup

[Chris Snyder]

Hans Zaunere wrote:

>After going through numerous iterations of authorization schemes (not
>authentication - that's fairly straightforward) I'm sold on roles based.
> 
>The roles model is simple - it simply answers that someone can play a
>role (or group of roles) or not.  Determining what to do is left up to
>the application.  
>
I agree 100% -- after taking a look at an early version of pAuth, I 
hacked together my own roles-based solution and have been quite happy 
with it.

An in-code example looks something like:

$editcontrols = '';
if ( $auth->hasRole('calendar::editor') ) {
   $editcontrols = "<a href=\"$this->url?action=edit\">edit 
$this->type</a>";
}

So if I assign user foo a role of editor in the calendar domain, then 
foo will see the edit link when he is logged-in. At the top of the edit 
script, I'll require a the editor role like so:

$auth->requireRole('calendar::editor');

If the user trying to execute the edit script isn't a calendar::editor, 
they get redirected to a no-access page and execution halts.

The role name is arbitrary, but using a domain::class notation gives you 
a lot of flexibility-- the auth object can automatically discover the 
current domain ( $auth->requireRole('editor') ) and you can define a 
class policy that says, for example, editors inherit the access rights 
of contributors.

I code in a super-domain (all) and a super-class (admin), so if some 
user has the role all::admin, they can do anything anywhere.

  csnyder