Feature Request: Role granted impersonation

[kcoop]

I frequently find that debugging a user's problem would be much easier if I could sign in with their credentials, but it's poor form to ask them for their passwords. I've found the impersonate mechanism provided by discourse.org to be invaluable for this, and it would be a very useful feature for Parse as well.

I haven't studied the code, but it seems straightforward. First, specify an impersonation admin role in the server config, then in the existing signin entry point check if the current user has that role, and if so, grant a session token without checking the password.

This would require zero change in the clients, and minimal change to the server. Thoughts?

[flovilmart]

From the dashboard you can gather the sessionToken, then make any auth'd requests through the API.

Also through the dashboard there's an API request builder where you can play any request

[kcoop]

Is there a way to explicitly set the session token from the client apis (e.g. IOS)? That's typically what I'm debugging.

Even if there is, it would require that I add custom client and cloud code to retrieve a session token before impersonating. What I'm describing would only require leaving the password blank on the client.

[natanrolnik]

You can use the becomeInBackground: method in order to become a user, from a session token.
Get the session token of one of the users in the role you want, and pass in that method. From then on, calls to currentUser will return this user, and calls to the server will be done using this user's token.

[flovilmart]

that would nicely work on iOS for example with an handleOpenURL(url: URL) (that you can call from safari with the session token)

[kcoop]

Ah! Don't know how I missed becomeInBackground. Thanks!

Yes, that combination will work. A little more awkward, but it already exists in the platform, so I'll take it! Thanks.

[kcoop]

It is still a little awkward though, and actually more work, since it requires implementing on all clients. If I submitted a pull request for this, would you consider it?

[flovilmart]

That's a little risky, as the roles are user defined, stored in the DB, elevated access roles imply other changes, and a very well thought plan.

This is not something that is at the core of parse-server security model, in short, you'd like masterKey access on clients with the ability to pick up any session token and start making calls a such.

[kcoop]

Ok, while this would be easy to implement, and debugging is so much clearer when following the exact same user flow, I get that it doesn't fit the current Parse model. One could do it by prepopulating the server with an admin user account and securely defined role (which might yield other benefits), but that's a philosophical change.

[kcoop]

Thanks for considering it anyway!

[flovilmart]

I'm not against this line of thought in general. For ex, right now we have _users that are solely created to edit content in the DB, they will never connect through the app. While _User and _Role allow us to do that, this doesn't seem quite right. This also extends with the email that is not returned when querying the user table, for evident security reasons. I believe column based ACL would be a nice addition to CLP and ACL as it would give a more granular control on what's what and fit the model.

What @natanrolnik proposed is a nice way of going, you can have a 'become' backdoor into your development/internal apps, this way you can impersonate the user's behaviour. With a small backend, that would give a valid session token, for such user, that would work too.

[kcoop]

@natanrolnik, becomeInBackground: works like a charm, thanks!

Added a button with a text prompt in debug mode, copy and paste the session token from the parse dashboard. Would be nice to just enter a username, but I'm all for going slow when it comes to security.

[flovilmart]

You could have a cloud function (protected in one way or another) that returns you the sessionToken for a particular username :)

[kcoop]

Yeah, might do that. But now you have me all paranoid about security. :-)

[flovilmart]

But now you have me all paranoid about security. :-)

That's better than the opposite :)

[kcoop]

Agreed!

[natanrolnik]

Excellent, @kcoop!