Implement impersonating users & roles in App & API #19085
Replies: 6 comments 5 replies
-
Would love to contribute the UXUI design for this case. |
Beta Was this translation helpful? Give feedback.
-
Heya! Thanks for opening this feature request! This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state! The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team. For more information, see our Feature Request Process. |
Beta Was this translation helpful? Give feedback.
-
@SeanDylanGoff Quick question! Seeing there's two, possibly 3 with #4959, variations of IDs to be passed in a header, should we go:
or rather
🤔 |
Beta Was this translation helpful? Give feedback.
-
Might be useful an environment variable or in-app configuration to control whether this function is enabled in server. |
Beta Was this translation helpful? Give feedback.
-
Love this! Quick couple of questions that come to mind:
|
Beta Was this translation helpful? Give feedback.
-
any updates on this? |
Beta Was this translation helpful? Give feedback.
-
Summary
Admin users will be able to send the headers
x-impersonate-user
andx-impersonate-role
.The API would then treat the user to have the given role / user id for all intents and purposes (permissions, presets etc).
There will also be a selector in the App for configuring if those headers are sent to the API. This selector should be easy to reach & refresh all data when changed
Basic Example
No response
Motivation
When developing a backend with multiple roles and role-specific presets mistakes can be easily overlooked, especially if users also have their own presets. I'm often confronted with problems that users have which are either role- or user specific. Having a way to impersonate users during QA and when responding to support tickets would make life a lot easier.
The current solution of either creating dummy users, or temporarily resetting user's passwords (making them reset it again after) is not good enough.
The extended idea of being able to impersonate roles in addition to users would for example allow verifying how a role change interacts with presets that the user already has without having to do the change.
Detailed Design
The API has to handle the 2 new headers as follows:
x-impersonate-user
: API treats requests as if logged in as the passed user, with the permissions of their rolex-impersonate-role
: API treats requests as if the currently logged in (admin) user had the passed roleThe App gets a new button visible on hover of the user icon (next to logout, only visible to admins). This icon triggers a modal for changing user & role, either using separate dropdowns or (probably better) using a more thought out UI element clearly distinguishing between the three use-cases.
Requirements List
Must Have:
Should Have:
Could Have:
Won't Have:
Drawbacks
Alternatives
Creating a dummy account per role (could be automated) and logging in with that. Kinda works, but is slow, hacky & doesn't solve the problem completely
Adoption Strategy
Shouldn't affect anyone or anything in the ecosystem. It will just be an additional button that most users won't notice if they don't need it, and two headers that need to be documented.
Unresolved Questions
No response
Beta Was this translation helpful? Give feedback.
All reactions