I have to make a small website
where I have 7 type of users. which can login into system.
some of users have permissions to only add equipments and others can add/edit. some of them can only view.
There will be some common fields for all users adding equipments in system and some fields will be user specific.
I have to track all changes in equipments with user changing equipments.
Can any one explain what will be best way to do this job.
Way in the sense table structure for users and tracking changes in equipments and users tracking for both login and what changes done by them.
Am using php and mysql database.
I don't want to go for CMS,Frameworks. It's a small application.
It sounds like you are going to need a role-based access control system. Developing one is not really a trivial task, so as already suggested, finding a framework or ready-made class that does the job would be a worthwhile start.
However, there's plenty of information out there on how to create one. Here's a few links to get you started:
Stackoverflow
Role Based Access Control
Role-based access to pages in PHP (dead link)
Other sites
A Role-Based Access Control (RBAC) system for PHP
Fine Grained Role Based Access Control (RBAC) system
Patterns Tutorial Series (part 1): RBAC Domain Model
A search for PHP RBAC will no doubt reveal many more.
Related
I am building a symfony based website, which has users and admins. Normally, I would let them use the same app, and display different pages for the admins by checking their permissions (I am using sfGuard plugin).
The Admins use the same modules as the other users, but the views are different. The admins can search for all user data and can see all the users at once. They can also edit anything.
But I am wondering if it would be better to use a backend app only for Admins? That's the way the jobeet tutorial does it. So the admins would go to this backend app instead of the other one that everyone else uses....
What would be the pros and cons of each approach?
Thanks.
If you're not using the backend admin generator, I'd keep everything to the frontend application, as I don't see major benefits for having a separate backend app in this case. You can separate the user experience for normal users and admins inside the frontend application just the same, all the way from their own login pages to "admin mode" template views etc. sfDoctrineGuard comes with groups and permissions so it's easy to set up. Plus you won't need to duplicate frontend app settings in the backend app just to make things work the same way.
This decision is a balancing act. The best answer depends on HOW DIFFERENT the functionality and permissions are between the two types of users. If your site is very complex, it will become easier to write, maintain, and test the code in separate apps. If there are just a few little differences, you will prefer the simplicity of only one app to maintain.
For example in our system, we have our own system admins which are allowed to do and see far more than the customer "admins". The customer users have different tiers of permissions with their admin level being the highest. However, even those customers can not access any of our backend, which has numerous modules they can't see, and completely different sets of forms. We even run these apps on different virtual hostnames even though it's within the same Symfony project.
Having separate apps like this allows you to more easily make sure the security is right by keeping customers completely out of the backend and all of its modules. We have some modules that are similar in backend and frontend, but the customer side has to have a lot more custom restrictions on which records & fields they can view/edit to keep them out of other customer's data.
If we tried to mix all those customer restrictions along with our super-privileged capabilities we'd have a nightmare of complex conditionals and queries and it would be far too easy to make mistakes and allow customers access they aren't supposed to have.
I'm trying to build an authentication system in my application, but I'm having some problems in deciding which is the best way I could acomplish what I want in CodeIgniter.
The website allows companies to manage their buildings. A company can have many buildings, and many users (when I say users I mean employees from that company).
In this website I would like two have (basically) four general kind of users.
Super Admin: This would be able to add new admins and new companies to the database, and give privileges to the rest of the admins.
Admin: This would be able to do different stuff depending on the assigned privileges.
Company Super User: This user would be created directly when an admin creates a new company. This user would be able to create new users for that company, and since s/he would have total permissions, he would be able to do everything that the other users can do.
Company User: Depending on the privileges assigned by its super user, this user would be able to do and see different data (for example, a simple user would just be able to see information from one of the many company buildings).
So, even though I've seen many authentication libraries out there for CodeIgniter, it would be nice to hear any recommendations about how I could design this "authentication role based" system, and if you particularly recommend a library that could help to accomplish this.
Appreciate!
There Are many libraries that already handle Authentication within Codeigniter, but the one I would recommend is Ion_Auth. It handles user permissions (groups) very well and I've actually done a detailed writeup outlining a good way to handle this situation with Ion_Auth.
I suggest FlexiAuth library which is a re-modified version of ion Auth, and has lot of features already built in, simply out of the box.
I've been developing a role based authentication system for Codeigniter called WolfAuth, here's the repository. It's still early days, but it sort of works. You can add roles, etc and then restrict functions and classes to particular user roles and usernames.
Use CI_aauth. I like this, this is very good from others auth.
https://github.com/kabircse/CodeIgniter-Aauth
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.