I think he was referring to this:
3 Likes
@Sam Sorry for reviving this old post but since impersonations are now logged could this feature be built in the future or is it in your list of things to work on?
4 Likes
Still not tracked per auth token, we would need a new column for that.
Over the years I have had so little motivation to do anything here short of adding tracking, I feel like impersonation is simply something to be avoided, the friction here can be seen as a feature.
6 Likes
Though I understand your reticence to improve it, I hardly think trapping people in a mode you want them to avoid makes sense as a feature. It has legitimate uses, which is why it was added and why I use it.
I don’t really mind being forced to logout to quit impersonating though. The problem is that I can’t figure out how to logout without clearing their notification count (because I have to click on their profile menu to get to the logout menu item.) This is confusing and unhelpful for the user being helped via impersonation.
Is there a url I can visit to logout directly? Or is there some other way to avoid this problem?
2 Likes
Simplest workaround is:
- Open a new browser
- Head to
/u/USERNAME/preferences/account - Find culprit device in “Recently Used Devices”
- Click wrench
- Log it out
If you are in the habit of always impersonating from an incognito session this should be fairly easy.
8 Likes
Thanks for the solution as well as the tip about using incognito mode.
2 Likes
A loud banner at the top to indicate impersonation, with a button on it to release the account would be a great way to round out this functionality.
This is what django-hijack looks like:
12 Likes
I really like this idea @John_Lehmann
Sometimes when I impersonate someone (albeit, not very often) I forget and keep trying to do admin type things and then realize I’m in someone elses account.
Another downside of the current process is that you have to click on the users avatar. I was impersonating a users that had 5 new notifications. When I clicked his profile, so I could log out of his account, it marks those notifications as read and no longer shows the (5) badge showing he has new notifications. How sad for him, when he returns! Hopefully he got some email notifications that will pull him back in!
Another community that I built and currently manage, is on the Higher Logic platform. I can’t tell you how much more I enjoy using Discourse than Higher Logic. But, now that I have that out of the way, I will say that I do like their method of impersonating users…
There’s a bar at the top of the screen, providing a constant visual reminder that you’re impersonating and a button to STOP, as well as a little orphan button at the bottom of the screen allowing you to STOP.
I don’t think they need both buttons. Top of the screen is sufficient.
I love @John_Lehmann’s suggestion with a more bold/obtrusive bar that stands out so you remember to get out of the user account before posting and doing other stuffs.
Not critical by any means.
I just came to meta, to see if there was a plugin for this, or something.
10 Likes
Just ended up needing this today. I use the impersonate feature to post category guidelines, or other pinned topics or replies in them under the @system account. What I currently do is post them under mine, then change ownership to @system, but what if someone has the topic set to watching, then they would see that it was me. I’m not necessarily trying to be anonymous when posting these, although, I just don’t want those posts under my name. I could make an alt whose purpose is to post these, although I would have to log in from a private window each time, which is bad ux.
2 Likes
I’d also like to be able to revert to my user account when done impersonating. This is possible with all of the implementations I’ve used for this feature in WordPress.
3 Likes
I agree, it’s not essential but it’s a huge change and I don’t think that putting a banner at the top with the logout button is so complicated… we could probably make a plugin but surely a simple change to the core would be better.
+1 to the @John_Lehmann idea.
4 Likes
I do wonder if this whole feature needs a rethink.
Impersonate was always a super sharp tool that was implemented as kind of a hack.
A non-hacky implementation may be significantly less creepy and far easier to justify as a default feature Discourse has.
- When you are impersonating a user you only have a “readonly” view (unless some special hidden site setting is enabled)
- Banner on top like @John_Lehmann suggested
- More ceremony when impersonating eg: with great power comes great responsibility
Overall the feature is very useful for debugging things, but acting on behalf of someone else is super dangerous.
I wonder if for starters @codinghorror it makes sense to make the current “impersonate” feature a feature that is disabled on Discourse sites and required changing a hidden site setting to enable? Not sure?
11 Likes
@sam agree sorry for the tag, but I’ve been randomly bringing this up for years and it’s a big deal for some. Impersonate is the one feature that makes user privacy a serious concern with Discourse, especially if using Discourse for an internal (work) communication and collaboration platform.
We have used it in the past, and are bringing back a discourse instance for use in our union. Not for the membership, but for the elected officers. For the time I administered the old instance, I was a regular representative like most. I’m now in leadership/administration of the group, so my role in the organization would not be at odds with a discourse admin’s abilities to see all materials within all categories. But it did then…
Our executive group had serious concerns with an admin having the ability to view their discussions within their (executive) privileged category. I hackily solved by hiding it from non executive group members with CSS (including hidden from admin), and pointing out how to view the logs to see if I ever disabled the specific theme component called “user privacy”.
The other MAJOR concern was an active representative who is an discourse admin (again rather than an a contracted IT guy) could just impersonate another user, read private messages, and tinker around in someone’s personal settings and goods.
All I can say is it would be great if there was possibly a way to focus on admins not having global viewing privlidges, but rather more of site administrative access, defaulting to only see contents they are assigned to. Plus a clear notification system to designated for all users to highlight if the admin staff is tinkering with this kind of stuff.
Call it something similar to discourse teams, maybe discourse professional. Something that’s not meant as much as an Internet forum but more of a business knowledgeable, collaboration and communication platform. Discourse would SHINE in this role, provided the admin eyes on everything capacity can be limited/curtailed or eliminated. (most centrally impersonate and reading messages vis profile/messages tab).
5 Likes
Personally, I don’t think I have a huge desire to impersonate a specific user, rather more so to impersonate a role/group member/trust level.
I found this the other day, where I have many private categories that show up to me as an admin, yet I wanted to see the how the topic list would look to someone at a T0, T1, etc., level.
Maybe this feature already exists and is separate from the impersonate function, I guess that beyond this, I’m not sure what else people use impersonate for.
Would this function suffice for most?
7 Likes
There’s so much on this subject over in The Impersonated user should be notified that they are being Impersonated. I still agree with the conclusions arrived at there. tl;dr it’s a rabbit hole, admins can do everything, if you don’t trust admins don’t have admins.
Maybe another approach would be to add some friction to impersonating by
- adding an “are you sure” popup, reminding that it will be logged and if they just want to test something they may prefer to create a test user and delete it again when done. just in time education, as it were.
- send the link to impersonate by email (this would have the added benefit of being able to log in in a separate window?) similar to the backup download
I also like the idea of an admin setting to disable impersonation, default disabled. Doesn’t even need to be a hidden setting but having the setting, like backup restore, will lower the risk that someone will get in the habit of impersonating another user or do it by accident.
3 Likes
If they have control of the system they have access to the data. You need admins you can trust, and your users need to be educated that there’s no expectation of privacy. That’s true of all software being used for communication and collaboration, even if you’re employing encryption across the piece.
You can’t even truly audit access to categories and PMs, any determined bad actor admin with root access can just grab a backup from the filesystem and read them directly from the database.
3 Likes
This is a great point. There are probably still some cases where impersonation would be useful, but this would almost entirely eliminate my need to impersonate users.
10 Likes
Everytime when an user have some strange issue that admin or his/hers pseudo-users can’t find or no other or just few users report.
Privacy is a relative question. I claim most of forums are in situation where an user doesn’t have anykind private info. So, impersonating should at least be an option. Automatic notice when it happens is not bad idea at all, even it is quite often unnecessary — but it is more open solution.
3 Likes
For the record, a trust level impersonation has been suggested here:
4 Likes
I think that’s fine, I always viewed this as a developer debugging feature, not a real “feature”.
5 Likes