The most recent release of BugTracker.NET finally includes features that make it a practical choice to use as a publicly accessible issue tracker. The most recent round of changes include:
- Allowing users to register themselves
- "Forgot your password?"
- Enforcement of strong passwords
- Ability to browse issues, and even report issues, without registering as a user.
So, after 5 years with no online demo, there finally is a demo of Bug at http://ifdefined.com/btnet. I have some worries about this public demo. Since BugTracker.NET is so configurable, I worry that people will make snap judgements that the demo installation represents all that BugTracker.NET can do. They won't realize that the demo installation is just one possible configuration. If my hosting account at GoDaddy allowed me to have multiple databases I would set up another demo, intentionally different from the first, just to give folks a sense of the range of configuration and customization options.
A second worry is that I have made some sort of mistake in my coding related to security, a mistake that will allow the bad guys to do ifdefined.com some harm. I try my very best to write secure code, but I have made mistakes over the years. I am worried about spammers and bots flooding my database with garbage, but so far, in the week or so the demo has been live, that hasn't happened. I have my demo configured to email me whenever my code throws an exception. There was a brief period where I got dozens of emails as a result of somebody probing my app for SQL injection vulnerabilities. That's a mistake I have made in the past, but as far as I know, I don't have any holes today. And as far as I know, the attacker wasn't successful.
I did have to make some code changes to BugTracker.NET for the GoDaddy hosting environment. Here they are:
- "Unable to validate data". In Web.config, I now set "enableViewStateMac" to false to make the app more compatible with being hosted on a web farm that doesn't support server affinity. By default, ASP.NET will try to determine if the Viewstate variable has been tampered with. The mechanism for doing so uses a key that is specific to the machine, so if the page is served up by one of the machines on the farm but the response goes to another, then the Viewstate variable will appear to have been tampered with. Another solution would be to hardcode the key into the Web.config, forcing the same key on each machine. I just chose the quicker fix. I didn't research how to generate a key.
- "Object reference not set to an instance of an object". My logic was failing when a request variable was missing from the request. It never happens to me using IE6 and Firefox, so I suspected the problem was happening when robots/crawlers were accessing my pages. In order to pin that down, I enchanced the error handling (see next item). Meanwhile, I fixed the code to better handle missing request variables.
- Logging and error emails. When BugTracker.NET throws an exception, code in Global.asax intercepts the error, writes info to the log, and optionally, sends an email to an address specified in Web.config. So, I was getting a dozen emails a day, but I didn't know the user, the User Agent (which browser, or which crawler), etc. Now I do. Before, there really wasn't any such thing as an anonymous BugTracker.NET user, but now there is.
- The logic for handling email attachments had been trying to create a temporary directory - actually, even when there weren't any attachments. My code wasn't granted permission to do that by GoDaddy. So, I fixed the logic to instead used a directory that I had created beforehand.
- It took me a while to release that GoDaddy's SMTP server listens on port 80, not 25.
In addition to all the these fixes, I also tried to make some cosmetic changes. Making the demo public, it was like I was getting dressed to go on a first date with a girl rather than just throwing on sweatpants to go buy some groceries. Actually, I think back in the day I probably did just throw on some sweatpants for some of those first dates...