craven.fr

While I hope that no one other than me was ever aware of it, there was a bug on this website a few months ago that started when I added an Adobe Flash object to the page (the Nike+ widget over on the right). If you kept the page open for a long time (like twenty minutes or more), it would suddenly prompt you for a password! (Which, whether you entered one or just hit cancel, didn't do anything.)

Besides looking unprofessional, this worried me for another reason: many of the websites on craven.fr are not open to the public and require passwords, while other sites are public and don't. The default policy is to close addresses to the public, as this is a standard security policy. So, if you just enter "www.craven.fr/" followed by something random (like www.craven.fr/somethingRandom, then it will ask you for a password too (and only if you have one will you then be informed that no such page exists.)

So what was going on? Why was Nike's flash widget seemingly trying to take browsers onto parts of my site they have no business going to?

With a little sleuthing courtesy of Firebug, which besides being the best tool in the world for debugging website development, also lets you monitor all the HTTP requests your browser is making, I was finally able to find the answer:

It's actually a quite innocent, if somewhat poorly thought-out, facet of Flash: although each <object> can define whether cross-site scripting is allowed, you can also have a global configuration file called crossdomain.xml. This can be handy, for instance, on sites like twitter or blogspot where individual clients may add their own Flash objects, if you want to enforce a global policy. (NB I am no Flash expert, so this is a vague description that might contain inaccuaracies, so if you plan on doing something with this file for your site, find proper documentation!) The hiccup is that since I do not have a file called crossdomain.xml, the server considers it an unauthorised access and asks unsuspecting users for a password.

In the end therefore I ended up putting a dummy (non-functional) crossdomain.xml file marking it public, so this random password dialog will no longer turn up. But boo to Adobe for requiring webmasters to add a file to their servers and penalise end-users who simply visit the site if they don't. This isn't like robots.txt which 404s graciously since it is only requested by bots; in this case a 401 actually bothers the user, due to a poor assumption on the part of Adobe's engineers (viz. that if the page didn't exist, there would be a 404; they did not take the legitimate possibility of a 401 into account). And thank goodness my default security is set to BASIC authorization: had I used FORM, the user would actually have been redirected to a new page!