-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Admin API to return an access token for any user of the server #6054
Comments
How should this play with devices, if an Admin "sudo's" into your account should it be a new device (which the user then should or should not be able to see in their devices list), should it just use a random device id? |
Yeah, would definitely need to be a new device ID (in order to protect e2e messages, unless the user explicitly verified the device). Ideally we should show in some way that the device ID relates to an admin (in order to provide some visibility of activity to the user, and what the device relates to, otherwise I can see people being very scared and confused at random device IDs popping up). So, maybe a random device ID with a "system_admin_" prefix, or something? |
Would probably make more sense to issue a new access token entirely to avoid situations where a user's set up is inadvertently modified by the puppeting actions. |
To reiterate from the above conversation, it sounds like we want to:
We probably also need a way for the admin to delete the token once done with it. Maybe this can re-use the delete device API. |
@rxl881 to be clear, this will result in a new entry in Element's "Where you’re logged in" list. Is that acceptable? |
could just call /logout? |
That would work too. I mostly wanted to mention it so that we remember to document what you should do afterward to remove the token. |
We may want to avoid creating a real device entirely, and just have a new access token that isn't related to a device. This has the advantage that it won't appear in your "Where you’re logged in" list, and won't cause any raised eyebrows from other users who see new unverified devices for the user. |
Description:
It would be useful for the server administrator to be able to grab an access token on behalf of any user of their server. As discussed with @ara4n it would be good to extend the 'whois' admin API to offer this functionality
This could be useful for admins of the server to perform actions on behalf of another user (e.g. a dedicated 'abuse' user or bots etc.) and could also be useful for (benign) account puppeting, e.g. provisioning of integrations etc.
The text was updated successfully, but these errors were encountered: