help with role based authentication

[eluser]Abhay[/eluser]
I want to add role based authentication in a project. It is like i should be able to select each role and should have an option to set whether a particular page is to be viewed by a user of that role.
I have done three projects and all of them uses a basic authentication. It only checks if a logged in person is admin or not.
So please provide a tutorial or a layout on implementing the roles.

[eluser]Udi[/eluser]
Its really not that hard as you might think.

Theres two ideas that you can implement:
1. Level-Based - each user has a level: 1,2,3,4,5.
You define that to view page X you [the user] have to be at least in level 3, so each user that has level 3 or more can view page X.

2. Permission-Based - you create users and relate each user to page. you have permissions table and table that relates user to permission.

The second option is much more powerful, but maybe you don't need it.

Is this information helped you?

[eluser]Abhay[/eluser]
Well..option 1 seems to suit me. IF we use option two,Wont the table size be huge?(if we relate each and every user to every page)..Any way thanks for the reply.

[eluser]Udi[/eluser]
Huge? i don't think so..
But you can create 'user_groups' tables, that group common permissions for users together... like add/edit of pages and gallery photos for example.

[eluser]Abhay[/eluser]
ok. I will try that. I havent yet worked with permission based codes. I guess i will use option two. That way i can fully understand the concept. Thanks....

[eluser]jbreitweiser[/eluser]
A third and more powerful approach is a workflow based approach. You have a workflow for each action or set of actions you want a user to be able to accomplish. Then you have roles that collect each set of permissions based on.. well.. role. This role is then assigned to a user. Then on each action/form/function/whatever you check if the currently logged in user has the workflow for that action. Its more complicated but gives greater control.

There are more ways to make this more fine grain but unless there is a real business need for it its not worth the effort to implement.

[eluser]Udi[/eluser]
I didn't understood your method - what you mean by workflow?
a set of controllers or methods inside controllers?

[eluser]jbreitweiser[/eluser]
A workflow can represent anything. So a workflow could be view document. In the controller for that document you check if the user has the workflow to view that document. It could also be an action. Say search for a user. Before running the search function you check that the logged in user has the search user workflow. That is what I mean by you can restrict access by anything. It is up to you to decide what a workflow represents.

Think of it as adding a layer to the idea of a role. Instead of always checking what role they have to see if they can do something, you check if they have the workflow to do it. The upside of this approach is you can create various roles with overlaping functions without having to go back and touch the code that checks your permission. Here is an example.

You have a search page for users. A role is defined called search.users. This allows you to access the user search page and search for a user. then in the results list you can edit or delete a user. Those two other actions that have their own workflows. edit.user and delete.user. If the delete button is clicked it will post back to the search page controller and call the delete function. The delete function will check that you have the workflow to do this action. If you click the edit button it will take you to the edit.user controller which will again check that you have the workflow to go to that page and redirect you back to another page if you do not. (As a side note you should check if a user can perform the action before you write the buttons for that action to the form.)

Now lets say you have 2 users. One is allowed to search for and edit a user. The other is the admin and can edit and delete a user. This is where having roles and workflows really helps. The lower permissioned user will only have search.user and edit.user. If he tries to delete the user he will get an error. The admin will have all three workflows.

As for implementation you would need at minimum 5 tables. Workflows, roles, roles_workflows, user_roles, and users. Then make a model that allows you to get a list of workflows for a user and call it when needed.

[eluser]Udi[/eluser]
Oh.. this is what I meant in the second option I wrote.. if specific user don't have a permission for user/delete - its shows an error or something.

[eluser]Abhay[/eluser]
I have one question.
Suppose a user shouldnt have access to a delete function. Is it better
1)to show the link and if the user clicks the link, he is redirected as he doesnt have that permission or
2)Dont show that link at all to that user.