Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

84%
+9 −0
Q&A How to properly deal with impersonation in a Web application? (security vs. usefulness for tech support)

If you've poked around the mod tools here a bit, you may have noticed that QPixel has an impersonation feature, live on prod. It's there for much the same reasons: so that developers can test and i...

posted 3y ago by ArtOfCode‭

Answer
#1: Initial revision by user avatar ArtOfCode‭ · 2021-04-07T16:18:11Z (about 3 years ago)
If you've poked around the mod tools here a bit, you may have noticed that QPixel has an impersonation feature, live on prod. It's there for much the same reasons: so that developers can test and identify issues that only appear for one user with a specific set of circumstances that would be difficult to reproduce.

If you've decided that impersonation in production is a required feature, you really only have two ways of doing it:

 * As you described, by executing permissions checks against the impersonated user but creating records as the impersonator. This requires you to change more code paths to be aware that impersonation is a possibility.
 * As we do it: with logging. Any time an impersonation is triggered, a log is automatically made to the admin audit log, which any admin can see. You can log as much detail as you need, right up to logging full details of every single HTTP request made while impersonating, if you need to. We don't go that far, but as long as you have impersonate-start and -end logs at minimum, then any actions the impersonated user takes between those points may have been impersonated.

You also, of course, have to define security policy for who's allowed to access the feature. In our setup, only developers have access to it - and a developer account is defined by a flag that's only settable via raw database or console access: there's no way to do it in the UI. While only a developer can impersonate someone, _any_ administrator can see the logs of it, which is how it should be: restrict the feature, but let a wider team be able to see when it's being used.