A little more on security and back doors
Following on from my previous post, I thought I'd talk a little bit about the designs of the projects that I am in charge of. Now to any of my Microsoft superiors who may be reading this post, fear not. I have never put any security back doors into my projects. It'd never make it past a spec review anyhow.
Instead, I would like to talk a bit about front-end vs back-end interfacing with databases. For example, we have a spam rules database with a web front-end to interact with it. The front-end allows you to do inserts, deletes, modifications to existing rules and limited search queries. It's a convenient interface.
But yet it is limited. Sometimes the web server goes down. Sometimes existing spam rules take a long time to load. Sometimes doing a search returns thousands of queries and is nearly impossible to find the one I want. In this case, searching the database itself makes sense. I have much more flexibility doing a MySQL search and specifying the search parameters for rules that I want than I have with the web front end. When I was a spam analyst, the web front end was all I needed. But as I moved on from analyzing spam to doing research into spam in general, I needed to do more flexible queries. In addition, if I ever wanted to modify a spam rule and the server was down, I could always do a manual db insert.
I call this manual db modification a back-door modification. It's actually useful from time to time but it is more prone to error. If I ever delete something but forget to specify which rule, such as drop * from spamRules (not the real table name), that would be a disaster. But on the other hand, doing a search query and piping the results into another script I wrote to parse some headers / IPs is incredibly powerful. With great power comes great responsibility.