Incognito

by 

| October 2, 2018 | in

“Software is hard.” – Donald Knuth

Shipping software is hard. Supporting software can be even harder if you don’t set yourself up for success. If you have customers, you can’t just push the Ship It button and run away.

Why is supporting software so difficult? One of the reasons is that re-creating what users are seeing can be difficult. In many systems, there is no way to act like a user. As the creator of the software you often have access to an admin account. You usually have access to the database so you can write queries to diagnose problems. You can access logs to try and figure out what is going wrong. But, you often can’t truly experience what a user is seeing. You’re left to making educated guesses.

This is where “Incognito Mode” comes in.

When building a system that requires a login, it is handy to build in the ability to masquerade as a regular user. We internally refer to this as “Incognito Mode.”

When clicking on the Incognito link next to “Bob’s Donuts,” we can pretend to be that user in the system. This “pretend” mode allows us to see what that user will see when running the system.

This all sounds great, what problems could there be? A big one. You are now allowing users to run as other users. This should immediately cause concern. When supporting “Incognito Mode,” you need to make sure of a few things.

First, logging needs to show some event for this. Second, all logging or auditing around actions needs to show both the admin user and the incognito user for those events. Third, you need to keep the number of people that have this ability to a minimum. Fourth, some systems shouldn’t have this ability.

Don’t assume every system should have an incognito mode, but it might be the right option for some systems.

author avatar
Chad Michel Senior Software Architect
Chad is a lifelong Nebraskan. He grew up in rural Nebraska and now lives in Lincoln. Chad and his wife have a son and daughter.

Related posts