Account impersonation & Apollo...

[Siyfion]

So I've been using a form of account impersonation for my admin team to manage other people's accounts and/or data without knowing their passwords, etc.

Loosely based on https://dweldon.silvrback.com/impersonating-a-user I use, @gwendall's https://github.com/gwendall/meteor-impersonate

Would it be possible to somehow integrate these two packages, so that the impersonation isn't "lost" in the Apollo data endpoints.

Perhaps @lorensr will have some words of wisdom!? 👍

[lorensr]

We use the localstorage token:

https://github.com/apollostack/meteor-integration/blob/master/main-client.js#L30

so maybe taking res.token

https://github.com/gwendall/meteor-impersonate/blob/master/client/lib.js#L9

and calling Accounts._storeLoginToken

https://github.com/meteor/meteor/blob/87681c8f166641c6c3e34958032a5a070aa2d11a/packages/accounts-base/localstorage_token.js#L44

[Siyfion]

It'd be nice to get @gwendall involved in this; though I'm not sure how active he is these days.

[Siyfion]

@lorensr I tried modifying the code to store the login token, but I can't get it working because in @gwendall's client code it seems to never have the token for the impersonated client, only for the "original" user. It seems to use Meteor.connection.setUserId(res.toUser); on the client and this.setUserId(params.toUser); on the server to manually set the userId.

[lorensr]

Could modify the method to always return the token of the target user

On Wednesday, November 2, 2016, Simon Mansfield notifications@github.com wrote:

@lorensr https://github.com/lorensr I tried modifying the code to store the login token, but I can't get it working because in @gwendall https://github.com/gwendall's client code it seems to never have the token for the impersonated client, only for the "original" user. It seems to use Meteor.connection.setUserId(res.toUser); on the client and this.setUserId(params.toUser); on the server to manually set the userId.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apollostack/meteor-integration/issues/44#issuecomment-257894516, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPVmIF7NVbI3JkZUvhDM8v35w1NBr61ks5q6Kg4gaJpZM4KbBm3 .

[Siyfion]

Tried that, but weird stuff™ happens. (I am briefly logged in as the impersonated user and then immediately kicked out.)

I wish I understood the impersonate code better, as I think it could use a bloody good tidy up and NPM'ifying, but I just don't get it well enough to try. Shame it's not a core Meteor bit of functionality really, as I'm sure it's useful for a lot of people. (Just look at the most recent reference to this issue!)

[jamiter]

I'll just do a quick plug of our package here that solved all of these issue:

https://github.com/Swydo/ddp-apollo

This allows you to use DDP for data transport. So it uses all the Meteor authentication that you're used to. It's probably not going to be the default implementation, see discussion here, but it helped us to use Apollo with a solid and backward compatible authentication mechanism. You can leave any questions in that repo.

[etyp]

@Siyfion did you ever have any luck implementing this?

[Siyfion]

@etyp No... I did it all a slightly different way. I ended up tweaking the server authentication logic to allow a login if the password matched a randomly generated short-lifetime hash. This hash was then provided to the administrators and they can access all the accounts in this manner.