userfrosting / UserFrosting

Modern PHP user login and management framework
https://www.userfrosting.com
Other
1.63k stars 368 forks source link

[Feature Request] Impersonate a user #877

Open alexuco opened 6 years ago

alexuco commented 6 years ago

Hi, I know when everything is working fine no matter, but in some cases when as an administrator have to be sure what user can see/reach and feel in her/his profile it give you some additional safety/calmfulness.

In my case, I'm developing some sensitive data and I must be careful on it. Thanks in advance.

cheers!

frostbitten commented 6 years ago

For auditing purposes, if not to just protect your own self from blame if a user turns into a bad actor, it would be good to log/flag impersonated actions with the id of the impersonator.

Silic0nS0ldier commented 5 years ago

I've been thinking about this for awhile now, and in my opinion the risk here is too great to make it a core feature.

Facebook got caught out with their View As feature (https://krebsonsecurity.com/tag/facebook-view-as-bug/).

It may be that we could make the core secure, but once people extend UF there will be major exploits introduced.

In terms of something more constructive there could be something we can do to make user impersonation easier to manually implement. Be it via a special sprinkle and/or core enhancements.

lcharette commented 5 years ago

If we are talking about permission impersonating, to debug a specific user permission, I don't see the issue since the master user has permission to do (and see) everything already.

Seeing record associated with a particular user_id, and worst, doing action on behalf of this ID, then that's a problem, yes.

Silic0nS0ldier commented 5 years ago

Its more the potential side effects I'm worried about. One-demand permission impersonation isn't a problem provided its done clearly and intentionally (talking backend here, full permission check method already allows a user object to be passed from memory), however to address what is requested a blanket solution would be required (so that the master user 'is' the specified user for a time).

amosfolz commented 5 years ago

I agree and administrators should never have the ability to impersonate a user (for the protection of the user and administrator). One can easily create a test user and assign it the appropriate permissions if they want to log on and actually see what the end-user will see.

What I think may be beneficial is a Permission Audit feature (I'm thinking along the lines of Microsoft Effective Access.) This could be something like selecting a user and then a specific URI/route and getting checking the response...

fembuelita commented 5 years ago

Another idea may be to copy a user's permission set from User A to user B, (or clone User A as new User B) provided neither user is the super admin. This would make it easier to verify permissions/roles/etc without impersonating a user.

amosfolz commented 5 years ago

Another idea may be to copy a user's permission set from User A to user B, (or clone User A as new User B) provided neither user is the super admin. This would make it easier to verify permissions/roles/etc without impersonating a user.

I could see a feature like that being useful.

There have been a number of concerns/opinions expressed. We need to land on a decision as to if this is something to add or not.