OSCON 2004 Sessions

I haven’t attended too many tutorials or sessions this year. Yesterday I saw Jim Winstead’s Practical I18N with PHP and MySQL and David Sklar’s Cleaning Up SOAP.

php-version5.gif Right now I’m sitting in Adam Trachtenberg’s PHP 5 + MySQL 5 = A Perfect 10. He quipped that it really should’ve been called PHP 5 + MySQL 4.1 = A Perfect 9.1, but the O’Reilly folks didn’t think the title was sexy enough.

Initially we looked at the mysqli (“MySQL Improved”) extension which offers prepared statements, an Object-Oriented interface, and the ability to query the database over SSL.

mysql.png Next, Adam started speaking about new MySQL 4.1 features. He gave some tips on how to use the new subselect functionality, reminding the audience to think carefully about using = or IN if the subselect returns a single or multiple rows. Then he spoke about MySQL 5.0 features such as Stored Procedures, Cursors and Views.

HTTP Caching and Cache-busting for Content Publishers

oscon-logo.gif Slides are now online (HTML, PPT) for today’s talk on HTTP Caching and Cache-busting for Content Publishers.

Abstract: A user’s web experience can often be improved by the proper use of HTTP caches. Radwin discusses when to use and when to avoid caching, and how to employ cache-busting techniques most effectively. Radwin also explains the top 5 caching ad cache-busting techniques for large content publishers.

OSCON 2004

oscon-logo.gif I just arrived in Portland, Oregon. I’ll be speaking about HTTP caching and cache-busting at the O’Reilly Open Source Convention tomorrow. If the talk goes well, I’ll propose it for ApacheCon this fall.

The conference hotel was all booked up by the time I made my travel arrangements, so I’m staying at the closest available hotel (which is about a mile away). Not sure if there’s something else going on here in Portland this week or if OSCON’s attendance spiked this year.

Open HTTP redirectors

There has been much discussion about open e-mail relays, but very little about open HTTP redirectors. An open redirector is hosted by foo.com, but will unintentionally send you to bar.com. This can have interesting effects on PageRank or can trick users into clicking on something that isn’t what it seems.

After many months of abuse by spammers, the rd.yahoo.com redirect server is now closed.

Yahoo! has used a redirect server for a long time for tracking clicks from one Yahoo! website to another.

http://rd.yahoo.com/example/?http://travel.yahoo.com/

Last year, spammers started using rd.yahoo.com in email messages to trick unsuspecting users into thinking that they were clicking on a Yahoo! website. They started sending out emails with links that looked like this:

http://rd.yahoo.com/example/?http://204.92.99.152/

Users saw the yahoo.com domain name and figured it must be some official Yahoo! site, not realizing that the server would redirect to another IP address. So we started blocking those types of URLs (easy to do since we’d never use a dotted-quad for anything legit). So the spammers switched to something a little more clever:

http://finance.yahoo.com:80@204.92.99.152/

The trick here was a misuse of the clear-text “username:password@server” authentication feature. It made it look like you were accessing a yahoo.com URL, but in fact were going somewhere else. These were particularly insidious, since they didn’t even go through our redirect servers, so there was nothing we could do to block them. Microsoft got rid of the problem for us with an update to Internet Explorer 5 and 6 that simply disabled the feature altogether. Mozilla followed suit by displaying a warning dialog box when this type of URL is used:

You are about to log into the site “204.92.99.152″ with the username “finance.yahoo.com,” but the website does not require authentication. This may be an attempt to trick you.

Is “204.92.99.152″ the site you want to visit?

So the spammers went back to abusing Yahoo!, but this time with actual hostnames:

http://rd.yahoo.com/example/?http://www.online-casino.com/

This not only tricks email users, but when used on the web can (in theory) also influence PageRank-type algorithms.

We had no choice but to either maintain a whitelist (lots of server-side state to manage) or implement a digital signature algorithm. We went with the digital signature approach. So now you can safely click through to partner sites:

http://rd.yahoo.com/example/SIG=10knc8oqv/?http://www.hp.com/

But if you try to recycle the same signature with a different URL, you’ll get a 403 Forbidden:

http://rd.yahoo.com/example/SIG=10knc8oqv/?http://www.online-casino.com/

Finally, rd.yahoo.com does what it’s supposed to do and nothing else. Frustrated spammers out there have probably already started to abuse someone else.

http://www.google.com/url?q=http://204.92.99.152/

http://www.google.com/url?q=http://www.online-casino.com/
:-)