Feed: Sean Coates: PHP, Web (+Beer) - AggScore: 75.2

A little over two years ago, when I got involved with the MontreAlers (note: yes, site broken... read on), the homebrewing club in Montreal, I was quickly nominated to be the sucker who would help take their aging and mostly-neglected web site, and make it somehow useful. At the time, the choice was simple: custom code or Drupal. Because custom code takes quite a bit of the most valuable commodity in life—time—and because I had (and continue to have) very limited spare time, I chose Drupal. I hacked together a custom theme (based on one of the prepackaged templates), spent a few hours configuring modules, and spent probably an equal amount of time shaking my head at the procedural and poorly-designed (for small values of "design") plugin/extension API. I grabbed some pre-built modules, and cobbled together a reasonable community site. We didn't need much, and Drupal + a few plugins solved most of our problems. The site was a hit. Membership in the club has climbed from a handful of members to what's often a troublingly large number of attendees to our monthly meetings. There's no direct correlation to the site, but I think all of the MontreAlers would agree that it has played a role in connecting with new likeminded people. As with any project whose maintainer doesn't have sufficient available time, the site got dusty over the course of the first few weeks, then dirty over the next few months, and before we even realized, the site was in a state of partial disrepair. Databases were upgraded, hardware was swapped, DNS was migrated, and PHP versions were updated. Each of these tasks of regular maintenance were met with heightened amounts of finger crossing, cursing and furious patching. After upgrades or changes, I'd usually get inquiries about why certain functionality mysteriously stopped working, which often lead to more furious patching, cursing and finger crossing. Over time, minor inconveniences can easily snowball into what seems like one large, insurmountable problem. The last straw for ongoing my relationship with Drupal was upon upgrading the PHP version on my server to 5.3. Admittedly, 5.3 is fairly young, but I was ready to take on the challenge. I'm handy enough with PHP's changes that I felt confident that I'd be able to take on any problems that Drupal presented. The obvious first step, here, was to update Drupal to the most recent release. I don't remember the exact date of the upgrade, but I do remember my feelings clearly. It was the day I started actively searching for a Drupal replacement. The upgrade was extremely painful. There was no clear path to upgrading from our old, stagnant Drupal install to the newest version. Updating the code was a bit painful, but possible. The Drupal upgrader/installer did take care of the database update, which was my biggest worry, and there was some documentation on how to do this on the Drupal site, but I had to dig pretty deep to find it (and I've since lost the links, so I apologize that I can't link to the references I used). There were two main pain points: I had to manually patch Drupal to work on PHP 5.3, and some of the third-party Drupal modules the club now depended on were not possible to upgrade. The patching for PHP 5.3 was not entirely unanticipated, and was reminiscent of making fixes in broken array_merge()s when jumping from 4.3 to 5.0. The real problem here is that Drupal still maintains its code in CVS, so I gave up on submitting my patches upstream shortly after diffing and trying (to no avail) to find their subversion or Git repository. I thought PHP was the last significant project to move from CVS to SVN, but I was obviously wrong. I fully expect Drupal will (or maybe already has) catch up to the current release of PHP (aside: they had plenty of notice to get their code up to speed—PHP 5.3 was certainly long in the tooth by 5.3.0). The real problem with the latest upgrade was that some of our modules not only didn't work with the new version of Drupal, but there was often no available upgrade for them. Our event calendar went missing, user maps (home addresses for club meetings) disappeared, our photo gallery is completely AWOL. There may be suitable replacements (read: alternative functionality in other modules) for some of our wants and needs, but the fact remains that maintenance is painful, and "upgrades"—often for the purpose of plugging security holes—take much more time and effort than I have to give. The underlying code in Drupal is old. It seems brittle. It doesn't do things I'd expect modern software to do such as have a good inheritance model (hint: it's [almost?] all prodedural code), have self-documenting or intuitive APIs, and it does tons of things that I simply don't care about (I'll probably blog on this last thing as a general poisonous open source trend in another episode). It's more pain than it's worth at this point, and I just need it out of my life. So, Drupal, we're breaking up. But I don't have anyone else to go (more on my short list in a near-future entry). (Here's the rhetorical paragraph.) Is it too much to ask for PHP code to actually be well-written? It doesn't even need to be perfect. Habari is certainly far from perfect, and it has warts, but on a whole, it's good code. Is the barrier to entry for most projects too low? Or is there just a huge lack of experience in knowing how to do things right? Maybe all of the best people are too busy doing other things? Or maybe it's a community-management problem...? I don't know. When it comes to software, and especially web software, I find myself always settling for "Least Worst." Habari is Least Worst. Trac is Least Worst. MediaWiki, PHPMyAdmin, Roundcube: all arguably best-in-class, but under the hood, they're often painful. I suspect my expectations are simply too high. Should I just lower them? I don't know that either.

This morning, via a colleague, John, I stumbled on a service called gdzlla that allows you to use Flickr as an alternative to the other de facto Twitter media posting services (twitpic, yfrog, etc.), from Tweetie on the iPhone. The idea is great, but unfortunately, the implementation is dangerous. Intrigued by an integrated media-posting solution, I started browsing the gdzlla site, and one of the first pages I saw grabbed my attention... in the wrong way. The idea of random web sites asking for credentials is hardly a new concept—especially when it comes to Twitter. Almost a year ago, news broke about a now-defunct site called Twitterank that was created by @brianoberkirch to illustrate the danger of carelessly sharing Twitter credentials with third parties. Since then, Twitter has implemented OAuth to avoid this exact scenario, but uptake has been slow: many third parties who provide a Twitter-related service still require users to submit their Twitter credentials to authenticate. What struck me about gdzlla's login page was the text at the bottom of the form: "(Your password gets hashed, we won't ever know it)." Thinking about ways to implement this (the password could be hashed in JavaScript, before the form is submitted, for example), I turned on Firebug, and discovered that the value is actually submitted with the form, in plaintext: I suspected that the gdzlla guys were not actually being malicious here, and would actually hash the value prior to storage on their side, but the text was misleading at best, so I tweeted about it: John noticed that I linked to the form processor page, which didn't work properly, so be brought that part to gdzlla's attention: This kicked off a conversation with @gdzl_la: Their reply shed some light on exactly how they're integrating with Tweetie. The iPhone app allows users to supply their own custom image service URL. When submitting media, if this value is filled in, Tweetie sends the raw image data (and other information, see below) to the third-party URL and expects to receive a URL where the media is hosted, in return. This type of integration is actually a really great idea. More apps should allow customization of third-party services. It's exactly how web services should be used. Unfortunately, as @gdzl_la pointed out in our conversation, Tweetie's actual implementation of this feature is horribly insecure, and prevents gdzlla from using OAuth—gdzlla doesn't even use your Twitter credentials to post to Twitter, that's Tweetie's job (as indicated in their instructions). So, why does gdzlla require users to submit their Twitter credentials if they're immediately transforming your password into a hashed form that would prevent them from actually using it to access the Twitter API? The simple answer is that this is the only way for them to integrate with Tweetie's poor implementation of a great feature. gdzlla presumably collects your Twitter credentials and then has you authenticate against the Flickr API. It then links the accounts to associate your Twitter and Flickr accounts, on the gdzlla side. The tragic flaw in all of this is that Tweetie uniformly sends the user's Twitter credentials to the custom image URL as part of the image hosting request. There's no other way for gdzlla to associate the incoming data with a particular Flickr account. Tweetie's instruction page says that it will send the following as POST data:

• username - Twitter username
• password - Twitter password (plain text, thus HTTPS is strongly recommended, and may be required by future versions of Tweetie)
• (other information such as the data for the media)

There's really no good reason for Tweetie to do this. They could just as easily ask the user to supply credentials for the third-party media hosting service. In fact, they absolutely should ask the user to supply this information on the setup page. Providing a user's Twitter credentials to third-parties is irresponsible at the very least, and leaves legitimate third parties in a pinch because there's currently no good way to implement authentication in this system—not even OAuth will save the day. (This also leads to non-security usability problems with services like gdzlla—handling password changes must be a huge headache for them.) Hopefully the Tweetie developers will recognize this problem and fix it. In the meantime, my suggestion is to avoid using any service that implements the Password Anti-Pattern, even if you trust them.

Tomorrow morning (in a few short hours, but I can never sleep the night before a trip), I will be flying YUL->ATL for the first city of the second leg of Code Works 2009. I'm really looking forward to this adventure, and the first leg sounded like it was a great time. We'll be traveling from Atlanta to Miami to the D.C. area and ending up in New York before I head home to Montreal in 8 days. I'll be speaking on using tokens as a better solution to problems often solved with regex and using Firebug and Selenium to save some sanity. If you can make it out, it's a great chance at a great price to get a crash course on topics that might not yet grace your developer arsenal. Hope to see you there.