# Thoughts about impersonate user
**URL:** https://meta.discourse.org/t/thoughts-about-impersonate-user/258795
**Category:** Community Building
**Tags:** impersonate
**Created:** [March 20, 2023, 7:54pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795 "2023-03-20T19:54:52Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [March 20, 2023, 7:54pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/1 "2023-03-20T19:54:52Z")
Following a flagged off-topic on _Discobot thread_ I wonder if Discourse community want to discuss if allowing **impersonate users on 1-single-click** is OK or could be something moved for specific scenarios.
From my own perspective that’s like using another people IP or ID. They are behaviors that are not aligned with ethics or moral (first than legal or illegal).
I think the same fits with impersonate as one-click solution where admins could post like another users with a single click.
I mean, changing some things on Discourse require manually entering the app, use Postgres and work in data from a lot of queries.
**Why impersonate is so easy, when it envolves a thread with multiple perspectives and different legally interests?**
That is probably don’t know by the majority of users and we all know that admins can enter the database and change things but that’s totally different from click a button and post like another user.
> Admins can suspend and ban users if something bad is going on the forum and they are legally responsible of the website.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [March 20, 2023, 8:02pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/2 "2023-03-20T20:02:06Z")
> [@satonotdead](#):
>
> they are legally responsible of the website
I’m not. So, somewhere that is true, somewhere isn’t. Same thing as 13 years agelimit. Or recording own phonecalls.
> [@satonotdead](#):
>
> Why impersonate is so easy, when it envolves a thread with multiple perspectives and different legally interests?
Because it is powerful tool when solving out issues, technical ones and others.
For me act itself isn’t unlegal. What I’m doing when pretending being someone else can be, though. It depends.
And IP is not person’s own property.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 20, 2023, 8:02pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/3 "2023-03-20T20:02:55Z")
As a developer, Impersonate is an absolutely _brilliantly_ useful function which helps with the development process, such that I can quickly jump out of an Admin role and into the role of a new user to check what they would see …
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [March 20, 2023, 8:06pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/4 "2023-03-20T20:06:05Z")
I think the point being made is that easy (and silent) impersonation might violate expectations, at least in some communities.
We shouldn’t be looking at this as a matter of law - it’s a matter of policy, and culture, and it’s perhaps the kind of policy where a site admin could choose one approach or another.
It’s sometimes useful to impersonate, but perhaps the person in question should get a notification. Perhaps for many cases, the person in question could _approve_ a _request_ to impersonate.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [March 20, 2023, 8:48pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/9 "2023-03-20T20:48:28Z")
> [@satonotdead](#):
>
> Why impersonate is so easy, when it envolves a thread with multiple perspectives and different legally interests?
Tbh in my opinion the feature is not needed and should be removed. But am sure the team may have reasons it is there. ie switch to a test user account.
As for the feature used to impersonate to poat as another user at least publically one could simply use 3 clicks to use change ownership.
Bottom line only have Admins un place that are chosen well.
> [@satonotdead](#):
>
> Admins can suspend and ban users if something bad is going on the forum and they are legally responsible of the website
This could be troubling as some Admins only maintain the interface like @pfaffman case with clients. As all admins have full permissions but don’t use things outside of there job. As mentioned one needs to check there region laws; However might need to be careful of travel.
Making the Api proposed to grant a user partial admin functions that a designer/maintainer requires.
> [@merefield](#):
>
> As a developer, Impersonate is an absolutely _brilliantly_ useful function which helps with the development process, such that I can quickly jump out of an Admin role and into the role of a new user to check what they would see
True but this could be done with using specifically test accounts. This us where it cones down to the integrity if the end user. This could be as the Op suggests be abused and corrupted use.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [March 20, 2023, 8:59pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/10 "2023-03-20T20:59:16Z")
I’m reminded of the warning in linux when the `sudo` command is first used:
```plaintext
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
```
That is, when using Impersonate for the first time, or every time, an admin could be presented with a click-through, with some message about respecting privacy and acting with integrity.
---
### Author:  [@ClawdiaWolf](https://meta.discourse.org/u/ClawdiaWolf)
#### Post date: [March 21, 2023, 12:01am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/11 "2023-03-21T00:01:05Z")
The impersonate function is a _good_ thing if you think about it for a moment, but not just for the reasons already brought up.
Impersonate logs its use in the admin log. Sure, an admin could delete the entry with the rails console or by a direct SQL query in Postgres, but that leaves its own trace (a gap in the log IDs that other staff will see if they look for it)
The lack of impersonate would actively encourage admins to abuse the far more sinister alternative that won’t be logged, and I suspect any dev reading what I just wrote has already figured out what I’m about to say.
Want to have a single log entry easily hidden and even be done months in advance so other forum staff won’t associate the two? You create a All Users API Key. 1 log entry, and you do whatever you want as whoever you want whenever you want, and unless it’s something that would normally be logged for the user you’re acting as, it would leave _no_ trace.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 21, 2023, 6:29am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/12 "2023-03-21T06:29:45Z")
> [@Heliosurge](#):
>
> True but this could be done with using specifically test accounts
They are often test accounts in a Dev setting in any case but setting up test accounts on Dev is extra work. This avoids you having to log off and log back in which slows your workflow and especially annoying having to set up multiple passwords which is not a pleasant experience, slows you down and doesn’t add anything of value in dev. With Impersonate you only have to remember the admin password.
I’m simply illustrating an additional benefit of this functionality for this specific use case.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [March 21, 2023, 6:36am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/13 "2023-03-21T06:36:35Z")
> [@merefield](#):
>
> They are often test accounts in a Dev setting in any case but setting up test accounts on Dev is extra work.
Somewhat unrelated, but this is way faster:
> [@I have add sql file of live site on local but login button redirecting how to login on locally on ubuntu](https://meta.discourse.org/t/i-have-add-sql-file-of-live-site-on-local-but-login-button-redirecting-how-to-login-on-locally-on-ubuntu/240884/2):
>
> Run you local development environment with DISCOURSE\_DEV\_ALLOW\_ANON\_TO\_IMPERSONATE=1 bin/ember-cli -u and then visit http://localhost:4200/session/system/become on your browser.
It only works in a dev environment. It lets you switch accounts from your browser’s address bar.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 21, 2023, 6:37am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/14 "2023-03-21T06:37:17Z")
Well that’s extremely useful too, thanks! That’s one for the great book of undocumented features! 😅
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [March 21, 2023, 11:31am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/15 "2023-03-21T11:31:05Z")
> [@merefield](#):
>
> They are often test accounts in a Dev setting in any case but setting up test accounts on Dev is extra work. This avoids you having to log off and log back in which slows your workflow and especially annoying having to set up multiple passwords which is not a pleasant experience, slows you down and doesn’t add anything of value in dev. With Impersonate you only have to remember the admin password
Test accounts really takes no time to create and in this idea they would be a standard part of the Discourse install much like Discobot and system. The “ **Impersonate** ” function would be kept save it would only function with say for example 3 or 4 test null accounts that could be modified to simulate users of various levels.
As has been said folks with high values and integrity may not use Impersonate for nefarious purposes. Though the use is temping nevertheless. That and if members of a site knew the admin could use there account to impersonate them they may loose trust in the platform. Atm impersonate relies solely on on integrity and has no optional fix unlike How “ **Encrypt Plugin** ” fixes the issues users of a Discourse Forum to make PM/DM private like emd users of a forum expect unless clearly spelled out that DM/PM are not secure and private as expected functionality by a community. On the Plus I asked specifically if Impersonate could be used to bypass **Encrypt Plugin** to which Sam explained and confirm it coulf not circumvent the pritection as it is End to End encryption.
I use Impersonate only on my testing accounts
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 21, 2023, 11:34am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/16 "2023-03-21T11:34:17Z")
> [@Heliosurge](#):
>
> Test accounts really takes no time to create and in this idea they would be a standard part of the Discourse install much like Discobot and system. The ,“mpersonate”
Not true. Creating test users every time is a pain. I often create fresh developer installs and run in the dev fixtures for expediency. (Those fixtured users do not have known passwords afaik) Then only have to add an admin account and impersonation allows me to switch between from the UI nicely. Job done.
I’m a bit perplexed by your negativity here … I was simply complimenting the platform for having a useful facility that I use regularly in my work, now you are attacking this functionality and my approach with the aim of what? To make our lives more difficult? I’m not sure I appreciate that very much!
---
### Author:  [@kynic](https://meta.discourse.org/u/kynic)
#### Post date: [March 21, 2023, 11:42am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/17 "2023-03-21T11:42:19Z")
What truly is the problem with the “impersonate” feature? why are you people making an issue out of nothing? anyway, this one is quite useful and even big tech uses these features if you talk about privacy then the admin can see everything and can do anything with the site stuff, Google, Facebook and all big tech of them do it. that is not something new anyway.
And why any dev would create an account if the issue is from the user end? In those cases, this feature is quite useful. If you have a problem then don’t use it.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [March 21, 2023, 11:59am UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/18 "2023-03-21T11:59:50Z")
> [@merefield](#):
>
> I’m a bit perplexed by your negativity here … I was simply complimenting the platform for having a useful facility that I use regularly in my work, now you are attacking this functionality and my approach with aim of what? To make our lives more difficult? I’m not sure I appreciate that very much!
I am not attacking it all. Simply pointing out that it is an easily abused feature that can create a plethora of issues. Baking in test accounts for direct use fixes the potential misuse by it not being available. As for the creation of a test account. I have opened a 2nd tab created account with a fake non email address snd tabbed back to my admin logged in account and validated.
Impersonate is definitely a useful tool that if Default test accounts or an Admin option to within the Admin panel could create null accounts that can be used with Impersonate. Would close the potential misuse.
As mentioned if a community is made aware that Staff Accounts can impersonate them they might not trust the community platform.
From what I have read of you and a plethora of other great ppl here would never likely misuse the feature. But having the open functionality of this feature could make communities less trusting of Discourse as a forum platform.
Having an open discussion should not be viewed as negative weighing pros and cons.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [March 21, 2023, 12:04pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/19 "2023-03-21T12:04:08Z")
> [@kynic](#):
>
> What truly is the problem with the “impersonate” feature? why are you people making an issue out of nothing? anyway, this one is quite useful and even big tech uses these features if you talk about privacy then the admin can see everything and can do anything with the site stuff
Sam’s Encrypt Plugin prevents Admin & Mods from viewing DM/PM much like how aps like Whatsapp advertises they cannot view conversations unless invited. So that closes the view DM/PM function that maybe viewed as a breach of expected privacy that is not clearly stated that they are not truly private.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 21, 2023, 12:04pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/20 "2023-03-21T12:04:16Z")
> [@Heliosurge](#):
>
> I am not attacking it all. Simply pointing out that it is an easily abused feature that can create a plethora of issues. Baking in test accounts for direct use fixes the potential misuse by it not being available. As for the creation of a test account. I have opened a 2nd tab created account with a fake non email address snd tabbed back to my admin logged in account and validated.
And now you have to create some test Topics, Posts, Likes with these new users … I could go on!
This is not efficient.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [March 21, 2023, 12:07pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/21 "2023-03-21T12:07:07Z")
So then advertise openly on all communities that admins can impersonate them. Efficiency hets replaced with mistrust.
@simon posted an in part okish solution in dev environment.
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [March 21, 2023, 12:09pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/22 "2023-03-21T12:09:17Z")
This is totally moot. If you really want to read users private communications, as an admin you can go take a look into the database (unless you enable encryption).
As a website owner you have in any case access to everything, can apply any modifications you like, turn on and off encryption, whatever.
When you use a third party system as a user you do not have any direct control of what people can do with your data.
In any case I’m not arguing about Production, my point was only to say this functionality _also_ has its benefits in Development and they are easy to demonstrate.
So from my perspective +1 on this. Now I’m too busy to argue this any further. Have a good day.
---
### Author:  [@kynic](https://meta.discourse.org/u/kynic)
#### Post date: [March 21, 2023, 12:13pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/23 "2023-03-21T12:13:43Z")
> [@Heliosurge](#):
>
> But having the open functionality of this feature could make communities less trusting of Discourse as a forum platform.
Then don’t use Google, Facebook, Microsoft, and all others since all of them do it. they don’t openly say that they can “impersonate” you. They can do all the things you can imagine but still, you trust them and you still use them knowing they can do anything so I dunno what truly is the problem, man. maybe you are worried about your forum mods and admins but still, all actions get logged if any admin uses the “impersonate” feature. so I am not able to understand where is the problem. if this feature was problematic then the discourse team wouldn’t have put it in the first place.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [March 21, 2023, 12:15pm UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/24 "2023-03-21T12:15:09Z")
> [@merefield](#):
>
> This is totally moot. If you really want to read users private communications, as an admin you can go take a look into the database (unless you enable encryption).
>
> In any case I’m not arguing about Production, my point was only to say this functionality _also_ has its benefits in Development
Which of course has merit. But having this available in a production environment is risky.
So what might be great would be like some other features to have this function tweaked to have it required to be switched on in Root server.
I do see how it can have value in a DeV environment as users there are likely aware it is a testing environment.
I already mentioned using Encrypt to close.that open function.
[Next page](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795.md?page=2)