xiven.com stating the blatantly obvious since 2002

Upgrades

The observant out there may have noticed that this site has just undergone some rather dramatic changes. Mainly the following:

• Non-crufty URIs. This means no more ?start=45&count=1 junk in the weblog permalinks etc. This has been by far the most complicated change, involving use of mod_rewrite and my own URI translation script that should hopefully ensure that links to pages with the old URI scheme end up in the right place.
• You can navigate the weblog by date, by category or just by viewing one big list (see the archive).
• My Digest Authentication implementation is now used for site security instead of sessions/cookies.
• The HTML and XHTML1.1 versions of the site are now generated by performing an XML parse of the source (which is originally in an XHTML2-like format) instead of the extremely hacky (and easily broken if you weren't very careful) regular expressions used before.
• Now using full and proper Accept header analysis to decide which format out of the available formats (in most cases XHTML1.1 or HTML4) to send to the client. No more evil user agent detection used.
• XML validation of new weblog posts. This will hopefully ensure that I won't accidentally invalidate the front page by adding a new weblog post that isn't valid.
• Plus it has a lovely new stylesheet. Alternate stylesheets may be reintroduced at some point.
• Media-specific style rules (try print preview and see what it does to the links… - you'll need a web browser that doesn't suck though).

This has been several months in the making, but I hope it'll be worth it. There are still a few things to be fixed. The news module of Omoicore (which is what the weblog uses) has been completely rewritten, and the Pingback client and server have yet to be implemented (I got impatient and decided to release early). Hopefully they'll be up and running better than ever in a few days.

Posted: 2003-11-30 23:38:18 UTC by Xiven | Cross-references (1) | Comments (6)

Absolute Power

Voidwars Game 4: Absolute Power has now opened for signups. If you don't know what Voidwars is, check out the slightly out of date manual.

Not much new this round as we're working on a pretty much complete rewrite, but there are rumours that your population may be starting to think for themselves…

Posted: 2003-11-17 04:17:54 UTC by Xiven | Cross-references (0) | Comments (0)

The ongoing war against comment spam

Whilst looking around various weblogs today, I noticed many posts concerning the evil that is comment spam. Fortunately for myself I have yet to be affected by this blight, but it is still something I am concerned about.

During my wanderings, one particular thing caught my attention. One entry on Adam Kalsey's weblog where a person replied to an accusation of being a comment spammer: they said that someone (one of their competitors) had posted the spam whilst masquerading under the accused's IP address.

Whether or not this was true, the possibility here is that because posting a comment just requires a simple form submit, a user can quite easily use a fake IP address as there is no need to receive the reply from the server.

I thought to myself: there must be a safe way to prevent this possiblity entirely using a simple bit of HTTP confirmation.

Note: from this point on, an understanding of HTTP is strongly recommended.

My first thought was to use HTTP Authentication to force the browser to send back some kind of response before it can initiate a POST request. Of course, this would cause the browser to pop up a login box, so that idea was quickly scrapped.

Then I thought: how about I redirect the POST request?. Much like this:

1. User posts comment
2. Browser submits form as a POST request to the specified action URI
3. Server tells the browser to send the POST request to another URI
4. Browser submits form as POST request to new URI
5. Server accepts the POST request and then tells the browser to GET the original comment page
6. Browser GETs the comment page, therefore returning the user to their post

This can be achieved by using a 307 Temporary Redirect followed by a 303 See Other. Unfortunately, a side effect of using the 307 code is that a conforming browser would alert the user that their POST request was being redirected (for security reasons). This is, unfortunately, undesirable in this particular case.

So I come to my final idea. It works a little like this:

1. User posts comment
2. Browser submits form as a POST request to the specified action URI
3. Server accepts the POST request and then tells the browser to GET a confirmation URI
4. Browser GETs the confirmation URI
5. Server accepts the confirmation and then tells the browser to GET the original comment page
6. Browser GETs the comment page, therefore returning the user to their post

This can be done by using 2 303 See Other headers.

An example in more detail:

1. User fills their comment in into a form. The form has method="post" and action="processcomment.php"
2. User click submit button. The browser retreives processcomment.php using a POST with the contents of the comment
3. processcomment.php writes the comment to the database, but gives it an unconfirmed status. It also generates a random number and stores it in the database with the comment.
4. processcomment.php then sends the following HTTP headers:

   HTTP/1.1 303 See Other
   Location: confirmcomment.php?postid=xxx&confirm=yyy

   where xxx is the unique ID of the new comment and yyy is the random number
5. The browser retreives confirmcomment.php?postid=xxx&confirm=yyy using the GET method
6. confirmcomment.php checks the equality of the random number then updates the database, marking the comment as confirmed
7. confirmcomment.php then sends the following HTTP headers:

   HTTP/1.1 303 See Other
   Location: viewcomments.php#xxx

   where xxx is the unique ID of the new comment
8. The browser retreives viewcomments.php, returning the user to their comment

This process is entirely transparent to the user.

Important note: this method will not prevent people from using proxies (anonymous or otherwise) to post a comment. All it does is ensure that the comment poster is not faking their IP address. Anyone who does use a fake IP will not receive the instruction to GET the confirmation URI and so their comment will not be confirmed. Now I may be completely bonkers, but I think that this could be potentially useful. More than likely, several people have already thought of this before me, but such is life.

Other important note: Note that this is almost certainly a violation of the use of GET and POST, since a GET is being used for an action which has side-effects (is not idempotent). In this case though, I would consider this use to be safe IMHO.

Addendum: this story of a weblog owner billing a spammer provided some amusement. ☺

Addendum 2: as has been pointed out to me in a comment, this is all completely pointless since HTTP sits on top of TCP which already deals with this scenario. Bleh.

Addendum 3: this weblog actually does now use this technique (and has done for a few months), not to solve the “fake IP problem” but instead to block badly written spambots that haven't been programmed to deal correctly with the response. It's really quite effective (though of course it doesn't block them all, and certainly won't stop manual spams), and it's quite nice how a problem arose to fit my solution. ☺

Posted: 2003-11-13 15:31:03 UTC by Xiven | Cross-references (0) | Comments (11)

I am here

I thought it was about time that I finally blogged about where I've been for the past 2 months…

The house in the above picture is where I currently live and work. Originally here for a 2 week contract to install a lovely new Linux server and to sort out various networking issues, I am currently charged with the task of replacing an ageing (but huge) MS-DOS database management system with a complete PHP/MySQL driven web-based intranet for the music publishing company known as Spartan Press.

Although it is still only a temporary job (length of contract indeterminate), I consider myself extremely lucky to be here: the work is good, the landscape is fantastic and all the people here are very friendly. A welcome change from being unemployed for a year anyway!

Plus I get to play with some fun toys. ☺

Posted: 2003-11-10 15:51:53 UTC by Xiven | Cross-references (1) | Comments (34)

Multiple Internet Explorer® versions on one computer

Yes it is possible.

Via Simon Willison, WaSP and various others comes the breaking news that it is possible to install multiple versions of Internet Explorer on a single installation of Microsoft Windows (despite Microsoft's protestations that it is impossible due to IE being too tightly integrated into Windows).

Downloads of modified IE5.01 and IE5.5 installs have now been created by Ryan Parman. Furthermore, Luke Redpath has created a nice set of colour-coded icons so that you can tell your IE versions apart.

The advantages this new information will bring to Web Developers are not to be underestimated. Before this, you either needed a computer for each version of IE you needed to test, multiple operating system installs on a computer or a copy of VMWare or Virtual PC (neither of which is free and both of which are quite slow).

Certainly, as far as I'm concerned, this will assist browser compatibility checking for Voidwars (most of the time we just don't bother to check IE5.x at the moment). I just wish we'd known about this 3 years ago when I was working on a totally IE-centric intranet at Tyco Electronics.

Let's hope someone figures out IE4 soon…

(Interestingly, as I was searching for a link for "Virtual PC" I noticed that Microsoft has now acquired Connectix and are now developing their own version of Virtual PC.)

Posted: 2003-11-07 06:40:33 UTC by Xiven | Cross-references (0) | Comments (4)