User impersonation

Get Help and Help Others
1

Some software has impersonation features, like gitlab for e.g.

I’m looking for a way to allow admins to see how pages look for users without admin rights/roles. Having getCurrentUser return an empty array does seem to do the trick, the question is, how to trigger that behavior.

I have a custom auth workflow, as we auth against gitlab, so I can do some more things then most other implementations.

I gues I could set a database value, that the user want’s to impersonate, but that sounds clunky.

Is there anybody that has implemented something similar?

2

This is often done at the auth level as many providers like Clerk and Supabase etc provide this:

The RedwoodJS Dev studio intends to have have user impersonation support, but for dev purposes – not to assume the role of a production user.

That said, I think there is another approach to do:

I’m looking for a way to allow admins to see how pages look for users without admin rights/roles

Isn’t this what storybook is for ?

Or it’s not “how they look” but actually “what the user is seeing if they are logged into product as well”?

3

Yes it’s the a latter

The problem is, I’m my own provider :smiley:

4

Well, then you do have control over how the authentication is checked – but that also comes with lots of responsibility so that your impersonation in production cannot be abused by others.

I would advise against just swapping the ids so to speak and instead consider for Clerk uses “actor tokens”

to impersonate:

Actor tokens are similar to sign-in tokens. They can be used for one-time logins, but they result in impersonated sessions. You can obtain an actor token from our Backend API.

Actor tokens need to declare the impersonator user (actor) and the impersonated user (subject). When Alice decides to impersonate Bob, they will issue an actor token. Alice is the actor and Bob is the subject of the Impersonation.

You can also configure the validity duration of an actor token by setting an expiration time, but you can revoke it at any time.

They still need to be authentication, they are still you – but have

  • the info on who to imerpsonate
  • an extra level of security in that they are super short lived
5

Yeah, I read the info for those a while back, but as we’re authing against gitlab, I’m unsure, if I can inject those or if gitlab would have to do that. Which would be game over I guess.

6

I can’t say I’ve ever seen impersonating someone on an app using a third -party access token like a GitLab or GitHub – that would mean you would be using the token they created and not your app’s. That seems troublesome to me.

7

Yeah, I think if I’m doing this, I’ll need to add a local storage entry, that leads to you being demoted, but having a button to get back to normal.

8

Maybe try to approach the problem from a different direction by asking:

  • why do you need to see the app running as if you are logged in as them
  • could you add some ad hoc logging to capture data while they are using your app?

What is the core problem you are trying to diagnose or solve and maybe it can be mitigated or experienced in another way?

If it is support, maybe consider other ways to report issues?

9

It’s mostly to help them understand/assure, which parts of the data they enter is public and which is not and how it’s displayed.

It would also be very handy for the dev team - for testing, as right now, if I develop/test, I need to change my role and if I have to remove my admin role for that, I need to go via the database or a colleague to get promoted again.