Amtrak, B-Movies, Web Development, and other nonsense

Day: September 29, 2012

eAmtrak, Part I

This summer Amtrak rolled out e-ticketing on all its routes. This is long overdue and a step in the right direction, not just in itself but for the efficiencies which should follow. One of the interesting features of the old system is that the paper tickets had cash value–that is, they were important in themselves. I once had to mail my actual ticket stubs via certified mail to 30th Street Station in Philadelphia in order to procure a refund (long story, and Amtrak fulfilled my request). With e-tickets Amtrak’s on the same footing as the airlines–your e-ticket holds no value of its own. This is a huge step forward.

And tomorrow I’m going to find out how well it works. I’m going to try to do all the following with my phone (I do have printouts available as a quick safety):

  1. Check a bag through to Chicago
  2. Gain entry to Club Acela (Amtrak’s lounge at Penn Station for First Class and sleeper passengers)
  3. Board the train (thus satisfying the gate agent, an institution Amtrak can abolish whenever it wants)
  4. Get my actual ticket checked.

I’ve already noticed a limitation that will probably require the printout for step #4. When you book a sleeping accommodation with Amtrak (in effect, a hotel room) you’re assigned to a car and room. This information is on the printout. However, it’s not visible on the phone. Doing this with the phone alone I would have no idea where my room was. The New York section has two sleeping cars (normally); each has two bedrooms, a handicapped-accessible bedroom, and twelve roomettes.

The last time I took the Lake Shore Limited was in May, before the nationwide rollout. I’m honestly curious to see the effect on boarding procedures. I’ve boarded at all four stations I’ll be using this trip (New York Penn, Chicago, Kalamazoo, Milwaukee) so I have a basis for comparison.

How to Screw Your Developers

I’m a Moodle developer by trade, with some administration duties thrown in for laughs. I see to the care and feeding of Lafayette College‘s Moodle sites. In addition, I handle some development and code management duties for the Collaborative Liberal Arts Moodle Project. All this is a long way of saying I push a lot of code around in a way that requires me to work with dozens (hundreds?) of developers whom I’ve never met. This means I have to document my work and develop against actual APIs. Further, working for an institution with thousands of students, staff, and faculty means that all our maintenances are published and (save emergencies) occur outside business hours. I can’t just shoot from the hip.

Gravatar is an online service which allows you to upload an avatar which will then be populated to other services. You don’t realize how many places use Gravatar until you upload an image and suddenly see yourself all over the web. It’s pretty cool. Gravatar provides a simple API so that you can add this functionality to your own website via web services. Moodle added support for Gravatars in the 2.2 release which dropped in December 2011. We turned it on at Lafayette since it’s easier than making thousands of people upload files.

So far, so good, right? Enter chaos.

Thursday morning we started seeing hundreds of broken user profile images on our Moodle instances. I knew we hadn’t touched anything. Stranger–we saw lots of Gravatars still appearing so it couldn’t be a recurrence of last Spring’s incident when Gravatar was unavailable. Cue an hour of tedious debugging until arriving at the conclusion that default image support had stopped working.

Gravatar’s API allows you specify a default image, to be used if the user doesn’t have a Gravatar. You may pass an image you host yourself, or use one of their stock images. Moodle uses the default headshot image, as defined by whatever theme you’re using. Moodle has a complex mechanism for determining which images to serve up, based on your current theme and context and whether caching is active. All image requests pass through theme/image.php, which acts as a clearinghouse for determining what image should be retrieved. This system is file extension agnostic for better compatibility and flexibility.

One of the benefits of collaborative development is that you’re usually not the first person to encounter a problem. I found that my issue had just been reported to the Moodle tracker by another developer who had come to the same conclusion. Here’s the issue. A Moodle request to Gravatar would look like this:

http://www.gravatar.com/avatar/6df0d771964ef4d1f10cab72149d8460?s=100&d=http://moodle.org/theme/image.php/moodleofficial/core/1348555103/u/f1

Let’s break that down. The URL contains the location of Gravatar’s image serving mechanism, an md5 hash of the user’s email address, a requested image size (s=100), and the default image url (d=<url>). If you try to use this now you get an error page which says “The type of image you are trying to process is not allowed.” Why?

I still don’t have the full picture but it appears that Gravatar made a change–unannounced and undocumented–to require file extensions in the default image. Several developers submitted support requests to Gravatar trying to confirm that this was the case. After several days(!) I got an answer back from one of Gravatar’s “Happiness Engineers” (blech). I’ve quoted the relevant part below:

We have recently implemented some changes that wouldn’t change our current documentation so much as an enforce that default images must actually be images. They should also be publicly accessible.

I noticed in the case you mentioned that you’re using a php file to serve up the image. For security reasons, that will no longer work.

This is nonsense. My own testing shows that they’re just looking at the extension, which is poor man’s security at best. Extensions can be faked. If they were serious about security they would eschew this extension malarky and just check the mimetype.

For me the greater issue is that this change happened in the dead of night, with no warning. Many hours of developer and administration time will now be consumed working around a change, leaving aside for a moment that the change is bonkers. What the support person told me perfectly explains the problem, yet as of writing the online documentation doesn’t reflect it.

Gravatar itself acknowledges on the same documentation page, when discussing displaying a Gravatar image:

If you require a file-type extension (some places do) then you may also add an (optional) .jpg extension to that URL:

I find that sentiment at odds with whatever process determined the change we’ve been discussing in this post.

So, that’s 760 words explaining the issue I spent far too much of my Thursday debugging. What does it all mean? That Gravatar is a neat, fun service which has no respect for the people who develop against its APIs. That may sound harsh but I maintain that if you have respect for your development community you don’t make changes like that without some kind of announcement or warning. That the change is technically deficient is also a cause for concern.

There’s a Moodle tracker item for providing support for alternative avatar services. It hasn’t gotten a lot of traction so far, but I intend to make a push there. Behavior like this makes me angry.

UPDATE: I’m amused, months later, to discover this blog post from Gravatar discussing the change, including the file extension requirement. It’s dated October 7, or over a week after the change and this blog post.