iCreativa User Authentication Suite:
Example 3.

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.