This is Example 3 of iCreativa User Authentication Suite. This example uses the more flexible and complex RoleAuth class.
As always this link to the install.php script and follow instructions.
In this example I want to introduce you to the concept of Roles for user
authentication managment. In the last example, where we used GroupAuth,
there where some problems of scalability. If we added just a new group to the system,
users in that group couldn't access protected pages of the site. This kind of
problem is fixed using Roles to check if the user can or can't access a
particular page or function of a page.
The problem and the solution arise from the fact that, even with out modifying the source code, groups CAN change (new groups can be added, or some of them can be deleted) but the functionality of a script WILL NOT.
When we define the actions of a script we give them descriptive names like
'createUsers', 'editUsersInfo',
'deleteUsers', etc... and we write functions that accomplish
those tasks. Well, users' roles are equivalent to those actions. If a user can
'createUsers', if he can 'editUsersInfo'
and 'deleteUsers' then he is a System
Administrator.
What this means, is that we'll have an 'admins' group,
and every user that belongs to that group has those roles.
But some other groups may also have some of those roles. For example, people of
the department of Client Service will need to
'editUsersInfo' in order to change lost passwords.
In practice, we create "Roles" for each and every action a script can take and assign some or all of those roles to the groups depending on what the users in those groups can do. This way when we create new groups we can assign a mixture of roles from other groups and inmediatly they have access to the areas the are allowed to.
For example, what if we wanted to show to a new client that administration app
that we wrote for another client and we are all proud of. We could just create
another group: "guests", for example, that will have
"roles" like 'showUsersAdmin',
'showDocumentsAdmin', from the "admins"
group but wouldn't have "roles" like 'createUsers'
or 'editUsersInfo' so he can't modify the database.
This example includes a mostly uncomplete user managment application with three groups created: "members", "admins" "guests". Each group has diferent roles, hence they can do diferent things here.
Explore the code of admins.php; especially, in the functions, how and where they require roles this way you'll get the hang of it.
You can start the example following this link.