1. Can we check some third person user permission? If I want check another user permission, not logged, how can I do that?
2. Can we overwrite (exclude) permission for certain user? If I have some group with permissions, for example, admin.users[read,edit,delete] and I want for certain user in that group exclude action delete from permissions, not changing all other users permissions from that group, can I do it in any way? How?
Auth is designed as an authentication framework, not as a user management framework. Accessing other user data than for the current user is considered a function for an admin panel where you administer your users. Since every application is hugely different, it is virtually impossible to create ready-made components for that.
Having said that, there is a dirty hack you can employ:
// save the current logged-in user $current_userid = \Auth::get_user_id();
// switch to the user you want to check \Auth::force_login($new_userid);
// check your access $access = Auth::has_access('some.permission[action]');
// switch back \Auth::force_login($current_userid);
Caveats:
force_login() will login the new user, and logout the current user. While doing that, it will set the session to this new user. If your code crashes for some reason, the user will remain logged-in as the new user, and has this users access to everything. So do this in a try/catch block to make sure you capture errors and restore the logged-in state.
Also, during the brief window between the two forced_login() calls, the user could open a second browser window and have access to the application with the credentials of the new user. This window is very small if you use the code above, but it is there and I must mention it.
And finally, if you haven't allowed multiple concurrent logins (which is disabled by default), the new user is logged out if she/he is logged in.
If you are feeling very adventurous, you could extend Auth_Acl_Ormacl, split the code that calculates and caches the users effective rights from the has_access() method to a separate method, and then add a new method in which you can call that for any user id.
2. No, not as such.
Permissions are cummulative, there is no real way to "negate" a permission. The idea is that you build up your permissions based on your security design. As you might have seen, the junction (or relation or through) tables between permission and users, groups and roles also have a column called "actions". This column can be used to filter on the list of permission actions.
So you can create a role record for "User administrator", that is related to your permission record, but only has "read,edit", and a role record for "User manager" that also has "delete".
This action column contains a serialized array of possible action id's. So if the permission contains
then the action column of the "User administrator" through record would contain array(0,1), and the action column of the "User manager" through record would either be empty (= all defined permission actions) or array (0,1,2).
Donate
