I just finished pushing a new version of the registration process. The last one had a nasty bug in it which was causing both failed registrations for users and also bad data which was clogging the b@b tubes.
Everyone should learn a lesson here as I am right now. If you're going to build a BIG web product, make sure you strongly consider test-driven development methods. Test-driven development means for every piece of functionality you build, you write some additional code that tests whether it will behave as expected when data is thrown its way (good data AND bad data). Sometimes you change a piece of code and it breaks something somewhere else and without some sort of test automation you'll never know (unless, of course, the site goes down completely). In the case of the bug I just fixed, if I had tests then every new version deployed to the web server would run once or twice through the registration process testing all conditions (respects User ID character limit, has Account ID associated with User ID, checks if email was sent, etc) to make sure everything is A-OK.
When you first start coding line 1 character 1, tests aren't really needed to do fast prototyping. Because if you make a mistake, it's obvious. There's so little code it's easy to isolate problems. Being able to prototype quickly is essential for starting a site. However this fast prototyping will inevitably leave you with compounding technical debt down the road. You'll have to take a break from cool features to clean up some messes.
Taking a step back to count lines of code, I've realized how big the b@b code base has become. There are 890 PHP files and 797 HTML files
![]() |
| cloc.pl output of /Sites/html/ |
On top of that, there's a bunch of regressed features that aren't actually visible on the site (everyone remember #hashtags?) but the code is still there. It's just turned off. There's also code that is just straight up useless left behind when some functionality changes. A good example is CSS.
--
So two things were fixed/improved:
- Registration flow actually works now: Email notification are sent and accounts are created all the way to login. If I drew a decision tree it might make one dizzy because of all the tweaks. This bug was actually related to the relatively new Account system which was a step to limit users to only 3 User IDs per hashed Account ID.
- Captcha: I'm not exactly sure why I thought I didn't need to have a captcha during the account creation process (the thing that asks you to type the characters that you see). That's pretty fundamental. Because of this over sight, a hacker was able to write a client side script that continually registered new accounts (I found ~1,200 suspicious accounts. The exact number is not known). Using the same methodology, he was able to vote up or down posts on his own. Clever. But not cool for not reporting the exploit. No hacker badge for you.
Cheers,
Jae

No comments:
Post a Comment