One thing I bring up time and time again is that you should never trust information from the client. Often this is framed in a Web and XSS/Injection context. It does however also apply to traditional thick software as well. Lets look at the a real world example of an issue in a commercial bug tracking system that happens because they are trusting the client.

One of the bug tracking systems that I use has a central server to which both web and thick clients attach. This is well and good. This server also enforces a pretty rigid workflow where only the person(s) currently assigned to a bug (or those in the magic admin group(s)) can edit it or re-assign it. This too is fine (and expected in this particular customer). The issue comes up however when the system is deciding where in the workflow a bug is.

In any company, all the computers should be polling a central time server so all the machine’s clocks are synchronized. In this situation the bug I’m about to describe would not occur. But what if a user shuts off the synchronization or intentionally changes the time / date to do some testing (or cheating around trial software time bombs)? Well, in the case of this system, the process gets really confused and bugs don’t go where you would expect. Here is a sequence of events that happened this afternoon:

  • Developer fixes bug dealing with time representation
  • Developer changes their system clock to November to verify outside of Daylight Savings
  • Developer assigns bug to me to verify
  • I verify bug against a different server so I don’t change my clock
  • I assign bug back to the developer to mark as really fixed (the workflow is not only rigid, but very loopy)

So who is the bug assigned to?

This is kinda a silly question since the whole thing is coached around a problem. The bug is actually assigned to me (and for some reason I cannot edit it — likely a different rule (or bug)). As far as we can deduce, when a bug changes state, a record is written into the database along with a timestamp. The bug then gets it’s current state from the most current (timestamp wise) event in the table. This means that even though from chronological perspective I assigned the bug to the developer last, according to the system the developer assigning the bug to me (in November) is the current state.

This, in my opinion, is a very silly bug that originates entirely in the fact that the application trusts the client. One way to avoid this is whenever you have an application that uses a database, use it for your time throughout the system. And of course that server(s) that are hosting the database should be synchronized to a corporate time server and that server should be synchronized to an atomic clock somewhere. DO NOT get the time from client.