>If your application doesn’t require a high level of user privacy, then you should be able to log into your site as a given user. Odd problems will pop up that only affect one user.
when the hell is this ever ok? even for a to-do list app. The closest we will come to this is a screen-sharing session with the customer
Logging in as a given user doesn't provide admins with any data that isn't already available in database backups and log files. If a startup only has one developer, then that developer already has access to every user's data, regardless of whether you allow frontend access.
There are many types of applications where that level of privacy would not be okay. But actually protecting the users' privacy is non-trivial. Short of encrypting all user-provided data, I don't see how you could prevent every startup employee from seeing any data.
Larger companies usually separate their operations and development teams, partially for this reason. Developers aren't allowed to access production data or servers. That at least limits the number of people with access to a trusted few, at the cost of a substantially more complicated development/release process.
I guess I am biased because I work at an organization with separate development, operations, and support groups. I work for the operations side of things and I can't image just letting support logging in as users. it just seems wrong.
It is very common to allow a support user to impersonate a user. A lot of the enterprise level authentication/authorization software packages support it.
As long as the action is logged it doesn't seem worse than anything else.
Yep. In fact, many users expect you to go into their account to see what they are seeing or what they are doing wrong, at least our customers do. It's the same data you can access in the database.
I suspect the point being made was that Joe First Line Support Guy shouldn't generally have arbitrary access to your database either. If you're handling sensitive information, including almost any personal data, then generally the number of people with root/admin/open access to the relevant systems should be minimal and tightly controlled, and everyone else should have controlled-by-need access through their own front-end.
Organisations (usually relatively small ones) where everyone can be root or access any user's file in the database so they can Get Things Done sound great, right up until the point where it turns out you hired the wrong person, they did something naughty with your database, and your whole organisation and/or its executives personally are sent to live in legal/regulatory hell for months/years/ever.
Scale all the things: 'Setup a caching layer (Memcached, Redis, Varish)'...if only it was just that easy.
Prep for scaling should be something like;
1. testing to see when you'll need to
2. monitoring so you know when
3. planning before you reach date / time from #2 how you'll do it
4. implement
5. test you've done #4 properly
6. release
7. repeat the whole process
Work out a methodical way that makes sense. "Setup a caching layer" is not that.
when the hell is this ever ok? even for a to-do list app. The closest we will come to this is a screen-sharing session with the customer