Impersonating another user
Feature available since 2.4.0
Using the impersonation feature it is possible for a Super Admin user to impersonate another user. To use this feature, the token being used for an API call should be belonging to a Super Admin user (specifically, any user having the
To impersonate another user, pass the header
X-Impersonate. The value of the header is the user id of the user to impersonate eg:
It is also possible to use the username or email of the user eg:
Security Note : When using this feature, we recommend the below steps to improve the security of your setup
- Create a new token to be used only for impersonation instead of using an existing token.
- Absolutely avoid using this token for client side requests. Use it only in server side communication.
More details of how this works:
Normally, the com_api framework sets the
JUser object for any API call based on the token passed in the Authorization header. Plugins can then access the user object making the API call via
This feature adds support for a new
X-Impersonate header which allows the API caller to set a different user than the one making the API call. The Impersonate header can accept either the id, username or email of the user to impersonate.
The Impersonate header cannot be used by all users, only by Super Users.
Consider the example below
In this case the user object available to the campaign resource will be that of userid 21.
This API call will return a 403 error since the user with token jjjjjj is not allowed to use impersonation.
In this case the user object available to the campaign resource will be that of userid 22 i.e. the user with the email firstname.lastname@example.org
This is how com_api works as of today, the campaign resource will receive the user object for userid 21