Recently I made a program. I forget to delete 2 line of codes. That mistake cost me $800 per day every day.
I was programming with PHP. If a visitor uses proxy it redirect somewhere else. Using debugger was impossible because some code contains ioncube. Because the program simply redirect somewhere else no matter what, it's hard to see which part of the code is executed.
So I put a bunch debugging info everywhere. I thought I'll delete them latter anyway.
The most natural way to debug is of course to put debugging info into a file. The problem is I often use proxy. So after I change the program, I often have to download the text file with filezilla. Often the text file does not show what I think it should show. Finally I decided to just display error on the web.
I considered having debugging mode. However, I am afraid I will forget to delete debugging info.
I considered having debugging mode if user do ?debuggingmode=1 for example. However, I was paranoid that somehow my competitor can guess the secret keyword.
I deleted most debugging info. I forget to delete one and that one only show up if users use proxy from the right country. Turns out I do not have proxy from the right country and didn't realize that. After the program works for 24 hours, I uploaded that to my main domain.
My competitor, using proxy, see the debugging code. He copy the idea and that's how I lost $800 per day.
In retrospect, I really have a hard time seeing where I went wrong. I have been super careful. Yet it happened.
How should one debug a PHP web application securely without exposing secrets to competitors?
Best Answer
The major mistake was that you reinvented the wheel. Instead of using default mecanisms for logging, you invented your own, which displayed the information within the page. A logging framework would rather store logs in log files, letting you to consult those logs later by SSHing to the server.
As for the bugs, producing bug-free code implies using specific techniques such as formal proof. Given their expensiveness, those techniques are appropriate for life-critical applications such as applications which control aircraft traffic or space shuttles, but are an overkill for
nearlyevery business application.■ See They write the right stuff in Fast Company magazine.
The article describes the methodology used at NASA, as well as the cost of producing software this way.
■ See Mechanizing Proof (Mackenzie 2004).
The book summarizes the history of automated proof of software, explaining the pros and cons of such proof, as well as the reasons it's not commonly used by businesses to write reliable software.
This being said, there are a bunch of techniques used for business applications to ensure software quality. Those includes but are not limited to:
■ See Code complete (McConnell 2004), Programming Productivity (Jones 1986a), Software Defect-Removal Efficiency (Jones 1996), and What We Have Learned About Fighting Defects (Shull et al. 2002).
Also, don't forget continuous integration and continuous delivery. It helps in automatically rolling back the app in production to a working version when a revised one appears to have an issue which was missed during code reviews and unit testing, but caught once the app is deployed.
■ See The Secret to Safe Continuous Deployment (video)
It explains what techniques were set up at Google to prevent bugs which couldn't be found before deployment from staying for too long in production. It also describes
pdiffand how was it used to catch bugs, including ones which were unrelated to presentation layer.