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?
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?
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.
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 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.
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.
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.
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.
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.