Today I fixed a rare caching bug upon this site, which is about the first real bugfix I've made for a few months.

This site uses Danga's memcached to cache pretty much every aspect of the content. This speeds things up and saves lengthy database queries.

The general way it works is that you'll have something like:

sub commentsByUser
{
   my( $self, $user ) = (@_);

   # check cache      
   my $cache = Singleton::Memcache->new();
   my $data  = $cache->get( "comments_$user" )
   return( $data ) if ( $data );

   # fetch from database

   # update cache
   return $data
}

We've all seen this kind of code before when working with caching, and I've posted similiar things here before.

Now that the setup is out of the way we can explain what the bug was and how it would manifest itself. The short version is that when users login to this site they are given a cookie, and on the server-side this is associated with a login session. The server-side session contains only the username of the user who has logged in.

The issue is that usernames are not case sensitive. So if you login to the site with the username "STEVE" you'll login correctly and your server-side token will contain STEVE. (Still with me?)

Now if somebody looks at the Steve user this will end up fetching the comments posted by this user - using the code above - and ultimately end up fetching from the cache, or setting the cache.

Here is where it gets interesting..

The query against "Steve" will work with the cache key "comments_Steve". If the user logged in as STEVE posts a new comment this will flush the key "comments_STEVE". Which means that nobody who subsequantly visits the Steve page will see the update - caching will query against "Steve" but the system will have flushed "STEVE".

The solution - Always lowercase the keys which are used by the caching module.

This fixes the issue, and any similar ones which might exist.

This bug was actually discovered when dealing with caching artifacts upon my fetish/kink dating site.