Charl van Niekerk » Blog: June 2005

Main

Latest

rel="alternate" for Feeds

I started this argument in my post Linking to Feeds a while back; however, I think I might still be getting it wrong.

Firstly, here is a quote from Modularization of XHTML - Defining Abstract Modules:

Alternate

Designates substitute versions for the document in which the link occurs. When used together with the hreflang attribute, it implies a translated version of the document. When used together with the media attribute, it implies a version designed for a different medium (or media).

Like most specs, this is quite vague. This leaves much to debate, but just so that you can see my personal standpoint, my own interpretation would be in the lines of "The substitute document must have exactly the same content, albeit in a different language, media, or type."

If you look at it from this perspective, using rel="alternate" to link to a feed is almost always incorrect:

A typical (X)HTML document contains site navigation, while a typical feed does not.
Many blog posts have both a summary additional to a full version, however mostly the (X)HTML versions contain only the one or the other while an Atom feed should contain both.

Then you could also get more, like the (X)HTML containing site-wide copyright info and the feed not. And the feed might contain additional metadata which the (X)HTML version might not. And the list goes on and on and on.

Ok, so I'm really just getting all purist on you now. But in some cases the differences are more significant than others, and eventually making these mistakes now could lead to bigger problems later (of course I'm totally unable to substantiate this ridiculous claim with any examples right now, but we'll have them when we get there).

Blogger Stuffed Up, Again!

After making my first post this week, I got quite a shock when suddenly my layout broke. It seems like the crap from Blogger is long from over.

The latest is that Blogger is inserting this into every single post right below the header:

<div style="clear:both;"></div>

This seems to be making custom layouts break left, right and centre (so to speak). I could also find no option to disable it, although I could have missed something (also note that I'm hosting on Blogspot).

Anyway, I guess this is to be expected from people that implement such atrocities as rel="nofollow"...

Here is a quick fix for your CSS:

div[style] {
 display: none;
}

This of course assuming that you're not using any legitimate div elements with the evil style attribute in your template. Also, I'm not taking IE into account here, since it already breaks terribly on this blog anyway.

Thanks to Krijn for helping me keep my head together in these difficult times... Luckily it will soon all be over! Stay tuned... :)

Misc. Open Source

I don't want to make separate posts for each one of these, so I'm just going to combine them together in this post (sorry, I know this is wrong out of principle).

First of all, finally we get an audio version of the Firefox Rap Song. Totally ridiculous and a waste of time... Oh well, it's fun!

Second of all, if you're still a bit scared of Linux why not try the LearnLinux site. Also, take a look at Linux-Tutorial.info for more.

Third of all, the go_open television series is now available via bittorrent after some complaining from myself and a few others.

Fourth of all, ehm, should this have been in some kind of list???

phpMyAdmin Authentication

For this article I will assume that you know what phpMyAdmin is all about.

There are three methods of authentication in phpMyAdmin:

Config: Using this method, you hard-code one MySQL username/password in the phpMyAdmin config file and then secure the installation by the use of an .htaccess file or equivalent technique.
HTTP: This gets the username/password for logging into the MySQL server from the user using HTTP Authentication.
Cookie: This is more-or-less the same as the HTTP option; however, it uses Cookies and HTML forms instead of HTTP Authentication.

The Config option obviously restricts you to only logging in to your MySQL server using one account per installation; not very practical for most situations. The HTTP Authentication is the most common option on web hosts since that allows each site developer to log into their own site's MySQL account and therefore stops them from "fiddling" with other sites' databases.

The Cookie option also carries similar advantages to the HTTP option; however, it also has two added advantages:

It's more user-friendly.
It's more secure.

A request for HTTP Authentication triggers most common user agents to pop up a dialog box to request the username/password to send from the user. This is fairly disruptive and, when using tabbed browsing, typically does not allow the user to view other tabs until the dialog box is tended to.

This could of course be changed by modifying the user agent itself, but this is mostly not very easy to do (or impossible for most users) since there typically aren't many preferences one can set to change this.

The Cookie option gives the user a "normal" HTML form. This is more familiar since most login systems work like that and also far less disruptive.

With HTTP Authentication, user agents usually keep all the usernames/passwords in memory until the user agent is closed, manual cleanup is requested by the user, or the username/password is rejected by the respective server. Every time the site requests authentication, the username/password is sent. This happens with every protected URI the user agent requests, thus typically causing the username/password to be sent over the line numerous times.

Every time the username/password gets sent over the line, it stands a chance of being retrieved by using packet sniffing. Therefore, one obviously would try and send the password over the line a minimal amount of times.

With Cookies, the username/password only gets sent over the line when the user logs on. An encrypted token is then generated by phpMyAdmin through Blowfish technology, and that is then stored by the user agent as a cookie. This is all that gets sent over the line from then on until the session ends. Much more secure.

The password could still be sniffed when the user logs on, and the encrypted token can also later be sniffed and used to "do stuff"; however, since it's only temporary you can only use it until the session ends (either by timing out or by a manual logout operation from the user). This means that Cookies can't stop hackers completely, but it's still a better option than the alternative.

This problem can fairly reliably be solved by using strong SSL encryption. As a principle, a password should never be sent over the line unencrypted, so even when making use of Cookies you would still be well advised to use strong SSL encryption at all times when accessing the phpMyAdmin facility (not only just when logging on, since as I explained above a hacker could still get temporary access to the database allowing him/her to make some changes, which is sometimes more than enough to create big damage).

My inspiration for this article mainly comes from the fact that the web is still terribly insecure. It's a sad truth that most site administrators don't think like the enemy - the malicious hacker - or simply are not educated about web security. Of course, in many cases security is not mission-critical, but in some cases (think e-commerce, etc) it is.

Anyway, if you're still not completely sure about SSL, take things one step at a time. Since most people are still using HTTP Authentication instead of Cookies in phpMyAdmin (really, I know nobody that uses the Cookie option other than myself at this point in time), I hope this article will prompt you to think twice before saving that config.inc.php file next time you configure your phpMyAdmin upgrade. :)

In one of my next articles (to be published soon), I'll be writing more about encryption (and in particular SSL), packet sniffing, and other login systems.

Mozilla Materials

I just finished the first release of the new Mozilla Materials website. It's a project on MozDev that I will be using to host and index the Firefox & Thunderbird materials (as well as Sunbird and Camino materials into the future) I and my "group" create(d). I used to host some of the stuff on Mozilla South Africa but due to the success of the materials I received many translations in non-South African languages and therefore much of it became irrelevant to that project.

I'm far from finished with the site, as I still have many great ideas but I'll just be adding bits and pieces from now on as I find the time. I'll eventually add an Atom feed too, but feel free to join the mailing list in the meantime.

Also, apologies for not posting for a few weeks. It seems like I just got over a bad case of "writer's block", but it's probably a good thing I got it since it opened some time for me to spend on other important projects. Expect more posts in the next few weeks.