Consider production-safe alternatives to `hijack`

[bickelj]

Is your feature request related to a problem? Please describe.

Some of our customers use the hijack (aka "Become") for more than debugging but there are some potential issues with this: lack of audits, obfuscation of who does what, ability to change passphrases.

Is your feature request related to an existing functionality? Please describe.

Impersonate or Become uses the hijack library. The general functionality is useful for reproducing issues even in production.

Describe the solution you'd like

An alternative to hijack that can be enabled safely in production.

Describe alternatives you've considered

An awesome django list shows three potential alternatives:

• django-loginas - “Log in as user” for the Django admin.
• impostor - Impostor is a Django application which allows staff members to login as a different user by using their own username and password.
• django-impersonate - Allow superusers to “impersonate” other non-superuser accounts.

Perhaps one of these would be safer to use in production, e.g. by logging impersonation events and providing a read-only view.

Additional context

We had a brief discussion about this in today's Maintainers Meeting.

The issue came up in 3961/3962.

Priority

• Low priority (annoying, would be nice to not see)

Affected roles

• Staff
• Applicants
• Reviewers
• Partners
• Developers
• General public

[frjo]

@bickelj I do not think the hijack module is particularly unsafe. It is the whole concept of allowing users to act as other users that is a bad security practice.

This could be alleviated somewhat by logging that clearly shows when a users acted as another.

But imagine you calling Amazon support (if that is even possible) and any person working there could loggin and act as you on the site.

[bickelj]

@frjo I see your point and agree. I'm trying to find a balance between the present reality of hijack enabled in some production sites and the best security practice of "do not enable hijack in production." Amazon operates at a different scale and so "any person working there" could be tens of thousands of people versus "any person working there" for a small funder would be more like five people. Regardless of the scale of privacy violations, I see your point. At the same time, some folks have found it extremely helpful when reproducing an issue to see the application from that person's view.

How do you typically reproduce issues that appear for user A but not for your user when logged into production? Is that reproduction feasible for a non-developer? What would you recommend?

[frjo]

@bickelj For support I think screen sharing (Google meet etc.) can work well.

If the organisation absolutely wanted to use this feature in production I would make sure they fully understand the implications. If they are ready to take full responsibility then turn it on.

I audit log would be a good feature in these cases.