I am doing new project in symfony1.4. Now this project requires users to log-in and browse, and as any project of this type requires a way of restricting users based on roles.
I don't want to implement this in obvious way, i.e to have roles attribute for each user and have pre-defined roles and assign these to users. The problem with this is it's not very flexible as more roles get defined later.
I was thinking on the lines of using an EAV model here, (not sure I can do that in symfony). What you guys think, do you have any better suggestions to make user roles much more flexible when they get added or deleted.
Also, what is the best way to display the page based on user roles, as I want some elements to be hidden according to the roles. Should I compare the role in each page and hide elements on every page? Is there a better solution?
Please shed some light on these.
Thanks
The sfDoctrineGuard plugin (http://www.symfony-project.org/plugins/sfDoctrineGuardPlugin) is a pretty comprehensive way of handling user authentication, groups and credentials. Users can be set permissions either individually or as a group, and access to specific page sections or entire actions can be restricted based on those permissions. You can set new user credentials in the controller code itself, e.g.
<?php
$this->getUser()->setCredential('editor');
?>
And verify that a user has particular permissions in views:
<?php
if ($sf_user->hasCredential('editor')) {
// stuff only for editors
}
?>
This page has lots of extra info on the plugin not covered by the readme file - http://trac.symfony-project.org/wiki/sfGuardPluginExtraDocumentation (although it refers to Propel rather than Doctrine). Also the following series of short tutorials is pretty useful:
http://www.finalconcept.com.au/article/view/symfony-user-management-sfdoctrineguard-installation
http://www.finalconcept.com.au/article/view/symfony-user-management-sfdoctrineguard-administration
http://www.finalconcept.com.au/article/view/symfony-user-management-sfdoctrineguard-securing-actions
And the Symfony tutorial page on users:
http://www.symfony-project.org/jobeet/1_4/Doctrine/en/13
Related
I am building a eCommerce platform. Where I have to make several user roles and specific permission for them. I have successfully created admin and default user roles and permission.
But I am getting so much trouble to show the views and menu items based on other user roles like Editor/Manager/CS Team.
I tried to do using different middleware for every one of them. But It's not working efficiently and even at all.
For the Admin role, I created a Admin Middleware where I am checking user role type and giving access. I defined the admin middleware on Route gruop.
Can you suggest me? - how to setup permission/views/menu items efficiently for different user roles?
Thanks in Advance.
Note: I am trying to do it without any package.
Yes you can make your own custom build library by setting roles,permission table in database and as soon as the user log's in you put all that information in session or cache. But doing so might get you in trouble in future coz lack of testing it's all feature, You have to be sure what exactly you are doing to manage it by yourself or else you can use already tested many time library like
laravel-permission
Using a well known and trusted library ensures that it will solve your problem, but take your time to read it's documentation and analyse if it contains all features that you want in your application.
You need to define policy.
Policies are a great way to protect actions on your Eloquent Model. Laravel Policies are the part of Laravel Authorization that helps you to protect resources from unauthorized access.
Please refer this documentation to how to register policy and how it works in views file:
https://www.larashout.com/laravel-policies-controlling-authorization-in-laravel
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.
How can i manage user permission?
i need a fast method to manage users (accsess to a page or dont accsee to a page) when they login?
You may want a simple solution but it's not a simple question.
At one end you could have individual permissions for each page for each user. That gives you a lot of flexibility but it would be an administrative nightmare. At the other end you could give users access or not to the whole site. Not very flexible but very easy to administer and code for.
The first is fine-grained. The second is coarse-grained. The whole point of finding an authorization scheme is to define one that is as fine or coarse grained as you need to balance flexibility and administration/development.
Two common schemes that may be of interest to you:
Give each user a type in the database. When they log in put that type (eg User, Admin, Moderator) in the session and check that on each relevant page;
Give each user one or more roles (so someone could, say, be both an Admin and a Moderator or just one of them or neither). This requires a separate table (users and userroles) and putting probably an array in the session to indicate roles but is more flexible than (1). Role-based authorization is very common.
There are many, many variations upon these two and just as many alternatives. Various schemes can be combined.
This is why generic authorization libraries for me fall short because they have contrary needs of being broad enough to cover a large number of use cases and being coarse-grained enough to be useful for the individual user.
Implement an ACL system.
A group of users form a role
A user may belong to many roles
Privileges are defined in the application - example, create user, post article. etc
Add privileges to roles via admin interface
Before the page loads, check ACL. If user belongs to a role with the required privileges for the requested page, allow user to continue. Else redirect to access denied page.
It can be easily achieved using third party libraries like Zend_Acl
Choose a library you are comfortable working with. But the basic idea remains same.
I am currently writing a CMS and remember someone (it might have been on here) criticise the existing CMS for not having a robust enough user permissions system. I've got a method planned out but it I feel it has fallen into the usual trap of being a bit too fine-grained which makes understanding and implementing it a horror for end users.
I think having a range of default user roles with permissions would be the answer to this, so I suppose my question is this:
What are the default roles you would like to see in a CMS and what sort of permissions would be associated with these?
Thanks in advance!
This is the "best practice" I have ended up with in most projects and am very happy with:
1. Roles
When it comes to roles, I recommend great flexibility, i.e. the ability to create and define user accounts and groups freely (roles like "contributor", "manager" etc. are not hard-coded, but put into a configuration file that can be changed per application). The role configuration is unaccessible to the user, but the engine itself should be free from hard-coded roles.
2. Rights
Rights is where things need to be easy to understand and implement.
I have made very good experiences working with, and checking against, very fine-grained rights on the code / API level:
see
view
edit
change name
rename
delete
move
change rights
etc.
but the user never sees those. For them, they are grouped into a very small number of "right groups":
Read Only
Edit
Administer = Move, rename....
The user never sees the "move" right, but only the "Administer" rights group.
That way, you retain the full power of fine-grained rights in your code for the future - you can, for example, easily accommodate for a rule like "interns must be able to edit pages, but not be able to change their titles, nor to delete them", adding a valuable asset to the CMS. For the end user, this functionality remains invisible, and the rights system easy to use.
I asked this question a little bit ago and got the following response.
admin //Manage everything
manager //Manage most aspects of the site
editor //Scheduling and managing content
author //Write important content
contributors //Authors with limited rights
moderator //Moderate user content
member //Special user access
subscriber //Paying Average Joe
user //Average Joe
Have you researched existing solutions like RBAC? Whilst such a system would most likely be complete overkill for the particular nut you're trying to crack it would at least help to boost confidence that you're on the right track.
That aside, the general roles I'd expect would be along the lines of:
Administator - Total control of the system, can view logs (as you should be logging all changes), etc. plus...
Publisher - Can put content live plus...
Author - Can create content
However, how these roles are applied across the system is where things get tricky, as a specific user would presumably have different rights to different content areas/modules.
For most applications, so I think it'll be true for CMSs as well, my customers usually prefer a rights-oriented approach. Here is how it goes :
You list the main actions. In your CMS that would be : Create and edit content; Delete content; Classify/categorize content; Validate content; Publish content; Manage users; Etc.
You define what actions are allowed or denied for each user
To make things a little better, you can create several roles (Editor; Administrator) to make typical users creation easier (by pre-filling the form when a role is chosen).
I have a custom CMS built on the Zend Framework that uses Zend's ACL to extends some basic roles (so you can deny resources specifically for additional users or allow others to access resources they normally couldn't). My basic roles go from CMS users all the way down to website "members" as follows (I just use one users table to store all my authentication).
Developer
Edit any content, edit layouts, settings, configuration. Use special tools that can call shell scripts and force cron jobs.
Admin
Edit any content, edit layouts, settings.
Author
Edit content.
Member
Can view the login screen, forgot password and bug report.
Now, Zend has a nice ACL implementation so you can easily extends your base ACL class and add new roles that extend from the basic roles. So I might make an "Admin" who has access to one of the Developer tools (e.g. purge or cache management) or lock an author to only be able to manage blogs (and not for example news).
I wouldn't necessarily dismiss the fine grained control system you have now. If you have one that is adaptable focus on hiding away the complexity by providing a simplified interface (eg use the facade pattern or the adapter pattern). The benefits are that you provide users with the simplified version (simple permissions like 'admin' can 'delete' a 'post') while still retaining the fine grained features should you need them later (eg more complicated permission handling is to allow to delete posts when the post is your own post in category X). Then you can provide an alternative to the simplified version for that need in some places.
Admin : The one with all the rights
Author : The one who has all rights to a specific content (like a blog author who owns the blog), also has the permissions to add/invite users to collaborate/view the content
Collaborator : The one who can edit/add content to which the author has given rights, cannot delete the content or invite/add more collaborators
Viewer : The one who can view the content if the author has invited to view
Editors : The one who can approve/edit all types of content
Having a fine grain control is not a bad idea if you expect advanced users/developers to use the CMS. But for novice CMS managers, the basic roles make the system much more usable.
Administrator - can create users + all below
Editor - can edit posts of others + all below
Author - can write posts, edit own posts
Creator - responsible for creating and editing content.
Editor - responsible for tuning the content message
and the style of delivery, including translation and
localization.
Publisher - responsible for releasing the content for
use.
Administrator - responsible for managing access
permissions to folders and files, usually accomplished
by assigning access rights to user groups or roles.
Consumer, viewer or guest- the person who reads or
otherwise takes in content after it is published or
shared.