### Author:  [@sau226](https://meta.discourse.org/u/sau226)
#### Post date: [February 28, 2019, 12:37pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/1 "2019-02-28T12:37:20Z")
How might I go about allowing specific users to impersonate others via a plugin?
For example say I have `@SomeUser` and `@SomeUserAdmin` on my instance. I want `@SomeUser` to be a normal user (no admin or mod) but see the impersonate user button on `@SomeUserAdmin` when logged in. This would be defined ideally from a site setting or user option although I can see why I might need to hardcode the user list.
If I log on as a user that has permission to impersonate another (e.g `@SomeUser` and `@SomeUserAdmin`) I should be able to see the impersonate button and all relevant controllers should allow the request to pass.
Does a plugin for Discourse exist that allows for this functionality. If not, is there any clues on where I should start hacking at first?
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [February 28, 2019, 2:53pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/2 "2019-02-28T14:53:41Z")
> [@sau226](#):
>
> is there any clues on where I should start hacking at first?
You will have to write a plugin that will overwrite the `can_impersonate?` method
>
---
### Author:  [@sau226](https://meta.discourse.org/u/sau226)
#### Post date: [March 1, 2019, 12:47pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/3 "2019-03-01T12:47:39Z")
Can someone please give me hints on why `@someuser` can’t impersonate `@someuseradmin` if I use the codebase linked below?
[https://github.com/sau226discourse/discourse-plugin-userswitch.git](https://github.com/sau226discourse/discourse-plugin-userswitch.git)
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [March 4, 2019, 4:48pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/4 "2019-03-04T16:48:23Z")
If you’re not comfortable writing such plugin I would strongly suggest you don’t use it in production as it might introduce security issues you might not have foreseen.
If you have the budget for it, you should ask in #Marketplace if there’s anyone who can help you?
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 4, 2019, 5:27pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/5 "2019-03-04T17:27:23Z")
Also, forgive me for asking, but why would you want to do this in Production at all?
The only person(s) that should have this capability are surely the Admins and then sparingly.
Impersonation is useful for checking out an update but it also has impacts such as updating their ‘last seen’ stats.
From a legal perspective, the admin is probably an agent or the owner of the company running the website. They have licence to view the data as part of their role. Giving people without such licence the ability to see people’s private information is almost certainly a GDPR issue? I think for some jurisdictions this would be a non-starter.
---
### Author:  [@sau226](https://meta.discourse.org/u/sau226)
#### Post date: [March 5, 2019, 9:01am UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/6 "2019-03-05T09:01:50Z")
Tl;dr: A forum owner grants a request by a forum admin to transfer their powers to a second, dedicated “admin” account who now maintains a normal account for day to day duties. This plugin would allow the user (the normal one) to switch into the admin account when needed (to perform admin duties). This fits in with the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) by only granting the user the tools they need for their day to day work and elevating priviledges when required. The user list is hardcoded in the source code (if I can get it working someday I may be able to consider a onsite setting somehow) and therefore this restricts abuse to those who are able to change the source code and rebuild the app.
This is a potential usage case I can see.
Say you have 1 person (for the purposes of this text his name will be John) and 2 users (for purposes of illustration we’ll call them John and JohnAdmin).
John does not want to be logged in as admin by default for whatever reason (e.g. the default admin ability to override category specific ACL’s, modify groups, change settings etc.). Therefore he has created a second email (or aliased it to his main email) and used that to create the JohnAdmin account. That account is admin and has a randomly generated password that will almost never need to be used.
John is just a normal user. Therefore the plugin’s intent is to override any restrictions on the impersonate feature so John can “switch” from John into his admin account whenever required. The admin account has the ability to impersonate back.
I can understand that only admins are able to switch back but John is already trusted as an admin by whoever has ultimate authority over the system. He only wishes to separate his admin duties from his normal user duties and the forum owner is willing to grant his request. Why not just fork the plugin (you maintain the source code for your install), modify the relevant lines of code (which are presently not working for me) and add it as a plugin. If you really have a privacy need the repo can be made private and a personal access token (or whatever the Git solution you use has) can be used in a specially built link to clone the private repo.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 5, 2019, 11:03am UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/7 "2019-03-05T11:03:18Z")
OK, I see what you are doing, so you are trying to time limit admin privileges by being able to convey those privileges, then take them away?
Why don’t you just make someone an admin for a short period of time (whilst maintaining the same account), then revoke that role? At least in that way you maintain the identity of the person in one account, instead of having to complicate the audit trail by adding the conveyance as another level of complexity and having to worry about who impersonated the admin account and when.
---
### Author:  [@sau226](https://meta.discourse.org/u/sau226)
#### Post date: [March 5, 2019, 1:50pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/8 "2019-03-05T13:50:15Z")
I don’t want to set a time limit on admin privileges.
I know of another company that has a feature built into their core app to allow their users to “switch” into other accounts. Sure this is mainly designed for people in that specific job that handles high privacy data (think PII/information of people under the age of 13) who log into their lower privileged accounts to do regular staff work and switch to their admin account with PII access when they need the access granted by an administrator account (their admins override ACLs much like the ones in Discourse).
**The point I’m trying to make is:** Some people (like me) may want a way that lets people start off in a normal/moderator account for day to day use (e.g. browsing the forum and posting) but give them the ability to log into an admin account with more access that doesn’t see day to day use (think toggling site settings, modifying the admin API and granting and revoking moderator status) or seems potentially dangerous in the hands of an attacker. By allowing for this switch people see only what they need to see and only assume the access they need for what they are doing at the time.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 5, 2019, 2:18pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/9 "2019-03-05T14:18:16Z")
This might be an interesting experiment, but for me this seems unnecessary and OTT.
As someone who runs 3 Discourse forums as both Admin, de facto Moderator and occasional contributor, I’ve never found the additional Admin interface presence an issue. I’ve never thought “oh goodness, I really must switch that off because it a risk or getting in the way”, but YMMV.
For a start you don’t have to hit the Admin route button and it’s not like it gets in the way. I’ve never accidentally navigated to the API settings, let alone accidentally changed them.
On the contrary, I’d find it very annoying to have to switch to another account to actually do any related work.
Anyway, apologies, not here to argue and you appear to have a strong desire to have it work this way, just personally not convinced I’d find it useful, perhaps others will.
---
### Author:  [@Earnie\_Baird](https://meta.discourse.org/u/Earnie_Baird)
#### Post date: [May 5, 2024, 2:50pm UTC](https://meta.discourse.org/t/allow-specific-users-to-impersonate-defined-users/110340/10 "2024-05-05T14:50:38Z")
Years later just wanted to say: This capability would be very helpful.
The use case is for support via chat. Let’s say you have several staff members w/o admin privileges:
- Staff member 1 will initiate a chat with customer 1 about an issue they are having and then goes on vacation
- Staff member 2 is now around and wants to pick up the conversation without needing to have customer 1 share all the details again
The desired solution would be for both Staff member 1 and Staff Member 2 to be able to impersonate a “Support Desk User” so they can all see the same conversation.
Definitely can see how this would need to be a custom plugin but it would be very useful.