Option for Admin to temporarily view forum as a different user

Ludachris

Well-known member
As an admin, it's not always easy to troubleshoot issues with how the forum is displaying buttons and content to various usergroups in certain parts of the site without logging out and logging in to an account with specific usergroup permissions. Even analyzing permissions in the ACP doesn't help sometimes. It would be nice to have a front-end option to temporarily view the site using a specified username, to help see what that user sees in all the public areas of the site (not conversations, for example). Maybe have a sticky bar at the top or bottom that allows the admin to get out of that mode when they're done.

There is an add-on that allows you to do this, but I'm hoping this request gets consideration as core functionality.
 
Upvote 19
Could you just set up a spare standard account and then log out and log into the spare standard account?
Yep, that's what I've always done. But you have to go and ensure all the permissions match the user in question exactly each time, and that changes for each user you're troubleshooting for. That whole process becomes pretty tedious, and sometimes you get the permissions wrong, hence the suggestion.
 
Last edited:
As an admin, it's not always easy to troubleshoot issues with how the forum is displaying buttons and content to various usergroups in certain parts of the site without logging out and logging in to an account with specific usergroup permissions. Even analyzing permissions in the ACP doesn't help sometimes. It would be nice to have a front-end option to temporarily view the site using a specified username, to help see what that user sees in all the public areas of the site (not conversations, for example). Maybe have a sticky bar at the top or bottom that allows the admin to get out of that mode when they're done.

There is an add-on that allows you to do this, but I'm hoping this request gets consideration as core functionality.

@Ludachris I am in the process of testing a vBulletin import inside a Xenforo testboard. After that import quite a few permissions are set wrong actually by the import, for example the administrator and moderators can’t see the Staf Zone anymore.

As you said indeed, a function to “see” the forum through the eyes of another user would come in very handy for testing purposes. I (as a first-time user of the XF Admin Panel) was a bit surprised it wasn’t available.
 
Last edited:
In my view this is an essential function that should be present in the core software. It's something I use regularly not only to help debug member issues and test permission changes but also to ensure that the forum presents a consistent experience for all members.
 
@Ludachris this is what you want and best of all it's free. I agree that it would be great to have it as a native XF feature.

 
This would be quite useful to have, but the thing that could keep me from using it, is if it would register the admin IP to the user account and thereby trip multiple account detectors and spam cleaner. That would lead to automatic reports and various addons acting on it. Then the hassle becomes larger than the benefit.

It would need to work without admin IP address attribution.
 
This would be quite useful to have, but the thing that could keep me from using it, is if it would register the admin IP to the user account and thereby trip multiple account detectors and spam cleaner. That would lead to automatic reports and various addons acting on it. Then the hassle becomes larger than the benefit.

It would need to work without admin IP address attribution.
No one wants to think about it, but setting it up that way sets up a situation where an admin with a grudge could silently log on to a user's account and send inappropriate messages under a user's name to get him banned, and there would be no IP trace for the board owner to know it wasn't the normal user. We should build forums with security in mind and part of that is having accurate logs.
 
It's certainly the case this type of functionality normally comes with a robust audit trail which is as it should be. @Alpha1 has made a valid point though. I'd like to think it possible to implement it in such a way that it doesn't create unwanted triggers for other functions.
 
A lot of times that I see this, you aren't truly impersonating any given user. Rather, the system functions by temporarily replacing all of your normal permissions with that of the selected user. You're not seeing it as them, but you're seeing as they would.

Discord's implementation works this way if you want to see it in practice, though rather than impersonating any particular user, you impersonate a particular role or set of roles. Their system is limited though because permissions assigned directly to the users cannot be replicated via this method. Adherence to RBAC practices is the way to avoid this pitfall, but not every organization applies those rules.

Because you're still logged in as you (you just have the user's permissions and groups assigned to you temporarily), this eliminates both issues - no IP logging because you're not actually logging into their account, and no malicious impersonation because any messages you send or posts you create are still under your actual credentials.

I would propose this or a similar implementation over direct impersonation. Direct impersonation, in my opinion, is too risky. Some could say "well then just make sure you only give that access to people you trust," but that falls apart if their account is compromised. I think it's much safer to keep the user context the same and replace permissions with a temporary set.
 
So you guys really want to see what other user groups are seeing. Just from your admin accounts. And look at one user's account at a time.
 
A lot of times that I see this, you aren't truly impersonating any given user. Rather, the system functions by temporarily replacing all of your normal permissions with that of the selected user. You're not seeing it as them, but you're seeing as they would.
It's a sensible compromise but it is a compromise. It wouldn't for example help diagnose issues that arise due to a member's settings.
 
It's a sensible compromise but it is a compromise. It wouldn't for example help diagnose issues that arise due to a member's settings.

Fair point.

If the impersonation method is used, I would like to see it be a readonly session. So I wouldn't want admins to be able to post on behalf users or send DMS.

Or we could call it out and say this message is posted by x on behalf of y so it doesn't seem like it's actually the user saying something.
 
Back
Top Bottom