Let's begin by saying that my model classes are User and Entries.
I've read the following tutorial: http://book.cakephp.org/2.0/en/tutorials-and-examples/simple-acl-controlled-application/simple-acl-controlled-application.html and I see they use an extra model called Group in order assign a role to users.
What is different in using a Group model, instead of a role attribute in User (User.role = 'admin')
What is the difference in adding Group to the ARO instead of adding User to the ARO, and then using an alias.
If I implement ACL, does that means I no longer need admin routing?
PD: I am new to ACL list, I have always authorized actions using a something like if($user['role'] == 'admin').
These are two different ways of handling authentication. If you only have a few controllers and one or two admins, you'll probably be fine with using the User.role method you have now. If you have multiple controllers and various users who should have access to different sections of your site, you should use ACL.
You don't need to create Groups to use ACL, but it makes life a lot easier. Instead of assigning permissions for dozens of different users, you can create two or three groups, set the permissions for those groups, and then assign each user to one of the groups. Then, if you ever need to add a new controller -- or even a new view -- you only have to do that at the group level, instead of for each user. (Take a look at this demo. Now imagine that you have another 10 controllers/50 actions and you have to set those permissions for 20 or 30 users instead of for 4 groups.) Of course, even if you are setting permissions at the Group level, you could always override them at the User level if you need to.
Admin routing is separate from ACL. Routing just controls the URLs you can use to get to pages. (See Cake PHP - Prefix Routing. You can use ACL control without admin routing, and you can use admin routing without ACL control.
Related
I am quite new to Laravel, but get most of the basics by now.
Currently, I build an application, where multiple companies each get an account that represents their main user, let's call him CompanyAdmin.
This user is allowed to create new users for this company and able to view all quotes from the company.
The newly created users, call them CompanyEmployee, can not create new users and only view the quotes they created themselves, as well as creating new quotes.
Now there is of course one SuperAdmin, which sits on the other side of the table. He views all quotes from all companies, is able to do create users as he pleases and can accept/edit quotes.
My current approach to do this would be to attach a user_id to all quotes and attach the users to a company, as well as giving them a role.
All the logic would take place in the controller, where I would check the role of the user and therefore read/save only the quotes, the user is able to edit.
However, it feels very dirty to do so and sounds like a lot of effort to maintain. If you would e.g. make another role for an employee of the SuperAdmin, you would need to change every controller.
I could not find a way to define the access rights per role per model, so when I call Quotes::all() it only retrieves the legal ones (same goes for saving of course).
Please guide me to a Laravel feature (or even package, but I have not used one before) that helps me get things done.
Looking forward to possible solutions that lead to low maintainance.
Best regards!
For authenticating different types of users and protecting group of routes that particular type can access you can use guards, for authorizing CRUD actions you can use FormRequest, I think you have everything you need under these 2 links, ofcourse you will need to read up on these, this is a good starting point. As for tables, you can have these:
users, roles, companies, user_role, user_company
And models:
User, Role, Company
from the doc
In addition to providing authentication services out of the box,
Laravel also provides a simple way to authorize user actions against a
given resource. Like authentication, Laravel's approach to
authorization is simple, and there are two primary ways of authorizing
actions: gates and policies.
Laravel has 2 concepts called Gates and Policies which we can inject it on models,(specially Gates), So when ever the queries are called upon the Model, the Gates make sure that the user has appropriate permissions.
You can read more here
I am using Phalcon as my framework of choice. I have hit a bit of a road block when it comes to structuring my website. I would like to use ACL to manage permissions to my website. But it seems ACL does not allow my to set permission values for 'parameters'.
Say I am creating a website that has user created 'groups' which only users with the correct permissions (set in the ACL) can view.
It might work something like this: website.com/groups/view/MyGroup
Group being the controller, view being the action and "MyGroup" being the parameter for the action defining which group to view.
I can only set the access permission for the groups controller or view action. Not the parameter.
Ideally, I'd use the database adapter for ACL and I would create a new user group for every group created in my app. I could have hundreds of groups, each with own set of users. I can reuse the 'groups' controller code for every group, because we always use the same controller/actions, except we point to different groups by changing the parameter.
How could I achieve this using Phalcons ACL library ? Maybe I need to structure things differently?
Phalcons ACL is based on 'Resources', in which a Resource can technically be anything you desire, you're not limited to controllers only.
http://docs.phalconphp.com/en/latest/api/Phalcon_Acl.html
The current ACL of phalcon is managing access between roles, resources and its actions. For example, if we want to allow specific role into specific resource :
$acl->isAllowed("Guests", "Customers", "search");
This check if role called "Guest" can access "Customers" controller for action "search".
In my scenario, we also have "Role Level", for example, Admin can access all modules and controllers, but, to modify the contents, an Admin should have minimum Role Level 2. To gain access to modifying website configuration, an Admin should have Role Level 3.
In addition to role level, we also want to assign which models a role can have access to. For example, Mr. A and Mr. B both are Admins and have same levels. But, we decided only to allow Mr. A to access "Accounts" models while Mr. B can have access to "Accounts", "Personnel", etc.
Here are my questions :
Does phalcon ACL support roles and levels ? Or, should I just create the custom validation?
What is the benefit of using ACL compared to creating similar validation functions?
If I have to create custom validation, where should I put it ? In the controller, or in the dispatcher ?
Thx
At the moment Phalcon does not support Role based ACLs. You will have to do something yourself to cover this. The feature has however been asked for and it is in the long list of NFRs for the project :)
The way I would go about it is use a combination of Phalcon functionality and custom programming. I would add everything to a base controller in the beforeExecuteRoute function so that whenever something is to be dispatched ACL is checked.
In a similar project to yours, I created two tables in my database:
Groups
------
group_id <- 2
group_name <- Admins
and have an ACL table that maps all actions to a group like so
ACL
---
group_id <- 2
acl_controller <- Customers
acl_action <- Search
You can easily extend this to have a collection of controller/action pairs to map to a Role. From there you can just create a simple function that would load the role based resources.
It is a bit of a workaround but it works.
I want to provide specified actions for different role in Symfony 1.4 project.
Project contains several database tables which values can be modified only by certain roles.
For example, an administrator gains access to CRUDs for all models.
Another role (let it be a consultant) can only retrieve (not modify or remove) results from specified models (not all).
How can I support such a feature in symfony?
I assume that roles for the project will be specified in advance.
One solution I was thinking about is creating modules and actions for each role separately (crud panels + one logging interface), but it sounds like a huge job.
Just wondering what the smarter way is.
I think the best way to achieve that is definitively credentials (it is for sf1.2 but ok for 1.4).
I recommend you to use sfGuardDoctrine to use some groups with associated permissions (which are credentials). You define a group admin, consultant, etc .. You associate some credentials, like modifiy, remove, create, edit, etc ..
And then, every time a user will log in, it will automatically have defined credentials (associated to him or by his group).
After, you have to check for every action if the user has can perform it:
if($this->getUser()->hasCredential('modify'))
{
// authorized action
}
Here is some more documentation for sfGuard (related to sf1.0 but it is good to understand how it works).
I am creating an web application and I at the point that i am starting to make backend choices. Now there are a lot of ways to go with this, so I am looking for some good points and back practices.
Some of the question i have involve:
Should i make a seperate table in the db for admin users
Should i extend make some classes to load the admin data and the normal data, or make seperate classes for the admin section
Where can i get some information on making different types of users
Just some best practices for a backend
My application is written in PHP with an MySQL database.
Keeping a separate table for admin users is nice, but only if those admin users aren't "regular" users as well - otherwise you'll step on your own toes trying to keep usernames/IDs unique but somewhat connected.
A couple things to consider:
Apache authentication (or Windows accounts on IIS) for admin users. Separate system entirely, but allows for overlap - a regular user can be a regular user, but they can't access any admin functionality until they authenticate through the browser. Works fine if you only have a couple specific kinds of user role (e.g. member & administrator only).
All users in one table, but with roles and permissions separate. This is the most flexible because you can get as granular as you need. For example, any user can "post comments," while an admin can "delete comments" and "ban users," but a moderator can only "suspend comments" and "mute users." As you add new features, it's simply a matter of implementing some new permissions & assigning them to the roles. Drupal's access control does this really well, worth a close look.
A good way to do it is to add a new field in the users table for 'rank' in order to differentiate between regular users and staff members, and possibly between the different staff member levels such as moderator, admin, etc. if you need it. Because an administrator should be able to perform all functions that a user can. Use
class Admin extends User { }
if you want to add additional functionality specific to staff members.
As for backend functions, that depends on how your site is set up. If you're using a framework, you can just add new functions to existing controllers and restrict access only to users with a certain rank.
For example, you might have a controller for ForumPost objects, but calling the ForumPost delete() function would require the user to be a forum moderator.
If you're not using a framework, you'll probably have to make your own pages for each backend function you need.