I am about to define permissions for users in my project. I checked the laracasts videos regarding ACL, Roles and Permissions.
I have a doubt. Do I need Roles for normal users?
I mean, in my project a user should be able to create / update / delete his own posts, he should be able to comment on his own posts and posts by other users and delete his posts and posts left by others on his own posts.
The point is: do I really need to define Roles for this kind of permissions? Shouldn't I just define some policies like can / can't post / update / delete etc. and only define roles for admins?
You don't necessarily need a full featured, powerful Roles/ACL system but if you are storing both admin and basic users in the same table then you do need something to distinguish between them. This could be something as simple as a Role field as a string on your users table e.g. Admin or Basic, or even a boolean is_admin field.
This would give you the ability to implement a Policy or Middleware to prevent basic users accessing the admin panel, and you can have permission checks to ensure a user can't update other users posts etc.
If you don't foresee needing anything more complex in future then this would suffice. However, as your app becomes more mature, you might wish to have a more advanced roles system, for example where a user needs to have multiple roles.
You don't necessarily need to define a role for every user...
It's probably a good idea to, however, you can 'hardcode' and make some assumptions about some of the access...
For example:
If you assume that anyone who is logged in can make a post and can edit their own post, you don't need to make a role for users to say "can_make_post", just have a check saying "if user is logged in, then let them make a post"
then if you say, have an admin area, then you can go "if user a has role
with the 'admin_access' permission, then allow access"
It would be a good idea to have roles for everything, as it allows more customisation, however, your the one designing it, if you don't need the customisation, you can probably just make some assumptions like above.
Related
As a freelancer, I used opencart for my clients, one table called users, another table called customers.
I tried wordpress + woocommerce, that's only one user system. I haven't really used this, just test.
If we use only one user system, I have a question. What/how account should the employee/staff use? Use the private email, like peter#gmail.com? This maybe not easy to manage. Any characters could be the email. like haha123#gmail.com. then we don't know who is who.
Or create a company's account like peter#nike.com, force the staff to use the real name.
But when a staff have two accounts, he login as staff at work time. And he buys things for himself. Then he resigned, leave the company. His work email is canceled, frozen, inactivated. Which means that he cannot access his own order records. And maybe the private order is still ongoing, haven't received, not paid yet. This caused problems.
What solution should we use?
WordPress is based on the Roles and Capabilities system. Users will have a role while Each role will have different capabilities assigned.
Whenever WordPress code performs an action as a logged-in user, it basically checks if the user has the capabilities to perform that action or not.
As you explained in your use case, in that case, a staff member will be assigned a role(let's call it manager) that will allow them to do some staff-related things and he can also use that account to make orders and buy things.
If he resigns then the site manager/admin will change his role as a customer and will allow him to use the website and buy things but he won't be able to staff related things, because the custom role will not have those capabilities.
And in some cases, his connection with any data that should be only assigned to staff will be removed and assigned to someone else.
In short, capabilities do all the magic here and instead of assigning multiple capabilities to each user, WordPress creates a role with a set of capabilities to make it simple, and we can assign that role to a user and change it anytime, to revoke or grant more capabilities.
Since I had problem with Passport multi auth, I wonder is it necessary to have an admin guard (and an admins table) or it's better to use the default guard (and users table) for both admins and users with the help of role and permissions? Which is better?
That's a really hard question to answer without more information, but I'll try looking at it from a few perspectives:
You have an application that has users that can turn into admins (and vice-versa)
In this situation, I would probably have a single table that contains an is_admin column and use the column to validate whether the user can perform administration tasks (e.g. by using Laravel's gates). The downside to this is that if you wanted to create a third type of user (e.g. supervisor), you would need to change the model used.
You have an application where users are completely separate from administrators
If you control the administrators and everyone else is just a user, creating separate guards could be used, this does allow for a lot of flexibility in the future if you wanted to implement different authentication flows for both administrators and users (for example, using SAML). If you were to add a third type of user (e.g. supervisor), you could then just create another guard.
You have an application that can have different (customisable) permissions for each user
In this case I would recommend implementing a roles table, a permissions table, a role_permissions table and adding a column called role_id to the user table. This provides the most flexibility and is also usable with the Laravel's gate system, but is probably the most difficult to setup and hardest to maintain.
For the application I develop, we use a mixture of roles and guards. We use roles for users as each user gets a customisable set of permissions. We then use a separate guard for API users which inherit the permissions of the user they were authenticated with.
Is there any way to login other users account for admin user ?
Currently authentication based on Meteor Accounts
I saw this post but didn't working at all now.
The feature is important for us because when user have problem in system then admin need to see it this by simulating user account.
Thanks in advance.
It seems you want to impersonate a user. This means that you want to have Meteor.userId (or this.userId depending on context) reflect the _id of a specific user both on the client and the server.
afaict the only way to do this is to login as the user. Presumably you don't want to ask the user for their password so you have a couple of choices:
Save their existing password, replace it (temporarily) with a password of your choosing, then after you're done impersonating their account, restore their existing password.
You probably don't want to ask the user for their password and you don't need to. All you need to do is set aside Meteor.user.findOne(userId).services.password.bcrypt, then reset the password to your temporary value, then restore the original bcrypt value later.
The downside is that the original user would not be able to login while you are logged-in. Plus it's really hacky.
Extend Meteor's Accounts package to provide impersonation capability in a more elegant manner.
You might also look at validateLoginAttempt. The docs are unclear as to whether a failed login attempt could be overridden with a successful one but if it could then that would provide another pathway to solve your problem.
Instead of logging in as the users, which requires their password and which is a total no-no, you may use rather alanning:roles and allow the admin to assign the role of any user in order to draw views based the user's role.
This requires a well designed role system.
As a plus you could then at least load the documents associated with the user who you want to support.
This requires a well designed document and data model.
But generally spoken you should rather focus on writing good tests (test driven development) for components as unit tests, integration tests and UI tests.
This will reduce the need to manually view the app as an end user a lot.
The most common end user problems can be reduced by creating a good knowledge base like a wiki or video tutorials.
Even if then an error occurs in the end user side, I would rather try to implement a well designed error log that allows users automatically create tickets on error which also include the error stack.
All the above methods are to be favored before logging in AS THE USER.
As #Jankpunkt has already mentioned alanning-roles I can add something you can use without installing any external package.
Just keep a type key in the profile object of the users collection. Then define some types like 1 for super-admin, 2 for admin, 3 for general etc. Then check the authorisation of particular action by checking the value of user.profile.type key.
Caveats: Make sure you are checking the type in server side. By default profile field is writable from the client end, so if you are putting type field in the profile object make sure that you are not allowing users to modify users collection in the client end.
Here is how to restrict client end update in users collection:
Meteor.users.deny({
update() { return true; }
});
Read more on roles and permissions here:
https://guide.meteor.com/accounts.html#roles-and-permissions
Django comes with a simple permissions system. It provides a way to assign permissions to specific users and groups of users. Like this： 'app_lable.model_name'. It may be convenient for the django admin, but I think it will be use difficult when I use it to control what people can to do with it.
For example, If I want to control whether a certain user can post a comment or see some portion content of my site. I have to config a permission group to him, but why not just add a user property like can_post or can_view_certain_portion? Its seems more intuitive.
So who can help me understand those things? Thanks in advance.
The reason to keep permissions in a separate model is to leverage groups.
So if you needed to change the permissions on many users at once you could simply update the permissions of the group they are assigned to.
Also since users can belong to more than one group you have more flexibility for customizating permissions per user.
Keep in mind vanilla django permissions are model based so if you need to limit changing only certain fields to different users you will need something more robust like django-guardian.
I am trying to come up with the best practice on how to set up roles for my controllers and actions.
We have a debate in our office. Should we give one role to the user and decorate our controllers and actions with a list or roles, or viceversa, multiples roles to an user and have controllers/actions decorated with the minumum access role required?
In my experience, it has been better to allow a user to assume multiple roles. This is the most flexible approach, and it will avoid an explosion in the number of roles in the system, because different people often wear different hats within an organization. This also simplifies your controllers/actions because you only need at most one role per.
I think this depends entirely on what you want your users to be doing. Is a person in an admin role only going to be able to do admin type things or everything?
We had a similar issue come up and we decided to go with 4 different roles and assigned multiple roles to users based on what they needed access to.