Proof of concept for collective.impersonate like behavior in volto

Plone Support Add-on Development
, , ,
1

Hi,

i recently stumbled upon collective.impersonate while searching for this exact solution for a problem we are facing.

We are currently on ClassicUI but plan to switch to volto in the near future.

Sadly collective.impersonate only works in ClassicUI.

So I sat down and worked out a little proof of concept for the impersonate functionality with volto.

I’m not very familiar with volto development in particular, but done a good amount of redux and react. So I would like to gather some feedback, whether the idea is viable. Maybe I’m missing something totally fundamental in the user session process.

The idea is the following:

Plone Backend:

  • Plone Backend Rest Endpoint /impersonate, which generates a new jwt and session for the given user id

Volto:

  • api action to call the /impersonate endpoint
  • a middleware which looks out for the IMPERSONATE_SUCCESS action
    • it updates the auth_token cookie with the new jwt token
    • it dispatches a LOGIN_SUCCESS action to update the token in the userSession state

I fork of collective.impersonate and added the rest action: Nimo-19 collective.impersonate feature/add_impersonate_rest_service

and I created the volto addon: Nimo-19 volto-impersonate

When this works and some people are interested in using this, I would like to polish and publish it someday.

2 Likes
2

Sorry for the late reply.

We used a similar approach to implement an impersonate feature for a client using Volto.

You can just dispatch the existing LOGIN action with the /@impersonate endpoint instead of adding a new action and middleware, if the endpoint returns the token in the same format as the /@login endpoint.

We also added a component to the personal tools menu so admins can open a dialog to select a user to impersonate.

3

I hadn't heard of this addon, but I like the concept.

I'm curious, as a matter of policy, is this something that people only use on a development copy of a site? Assuming you only give this to Managers it never grants privileges, but it could make an audit trail less useful. Consider: person X created an incident and we see that person Y added them, or granted them some privileges. Probably most people don't care about that for their sites, but for particularly sensitive data that may be a requirement. The audit trail would have to consider that it could have been any Manager that actually did this.

Is there any way to keep track of the "real" user in the new session? Annotations on the request wouldn't work, I don't know if there's such thing as session annotations?

4

For the implementation I mentioned above, it is disabled in the production site and only enabled in staging and development.

For another similar implementation, we stored the original admin user in a variable in the session, logged it in some cases, and provided a way to stop impersonation and return to the original login.