> You may not be able to do all write operations while spoofing (e.g., updating payment methods), but most operations are read, and even the write ones are reversible. Don’t let this scare you, embrace it.
Yikes. I would not allow admins to change customer data in production by spoofing the user’s identity. There are too many ways for that to go wrong. Instead, copy the user data into a test environment and mess around with it there as much as you want.
I've implemented this type of 'spoofing' system. Nothing happened. It was super valuable, both for the customers and the customer success team. Long as there is an audit log, things should be OK until a certain scale is reached.
Also most companies have a backoffice that should provide access to the information and possibility to apply actions to the state. So just giving access to this information in a more limited way that mimicks the customer's view is a no brainer for early-stage.
* Small company; two-sided marketplace with some hundreds of thousands on one side, and some tens of thousands on the other, so rather small scale.
It's my current predicament. I'm consulting for a 'serverless' startup that shuns away any sort of backoffice and / or impersonating. They also don't store logs, just what the infrastructure provider offers, so, a tail to live prod data.
It's just horrible to investigate a customer issue and is a frustrating experience both for the devs and the customers.
"Hello, <customer>, do you mind doing the exact same operation you were complaining about right now?", then it's shifting through microservice logging hell.
Yikes. I would not allow admins to change customer data in production by spoofing the user’s identity. There are too many ways for that to go wrong. Instead, copy the user data into a test environment and mess around with it there as much as you want.