Finally I found the correct information in a blog post, you need to use Puttygen to convert the Amazon .ppk file to OpenSSH format. The OpenSSH format can be used by the Mac OS X (OpenSSH) ssh client. You also need to chmod the direcory where you store the OpenSSH key so it will only allow read access to other users.

After that a simple text file with the following content:

ssh -2 -i /Users/xxxxx/amazon_ssh.key youruser@yourserver.com

And save it in the Desktop area to have it available on your desktop (or save it elsewhere, whatever you like).

The package contains the library, the data model in the form of MySQL DDL instructions, installation documentation and PHPDoc API documentation. It comes with three applications: a management application, a demo application and a test framework. The demo application shows you how to integrate the library with your own application.

The code is not OOP, I already had one complaint about that so if you’re completely hung up on OOP being the only acceptable thing in your life you might want to pass on this one. Then again if you’re a bit more mature you might still want to take a look and see how much you can salvage for your own project, or decide to take the code and go OOP bezerk on it and improve after your own tastes

The library doesn’t contain any output other than arrays or true/false in accordance with the NIST RBAC formal API description (in Z notation). The management application follows a simple MVC pattern with the controller just passing on requests to the model and the model only respond with arrays or true/false returns. The view is based on a simple XHTML template.

There’s still a bit of work to do with the session management part of the management application, some sessions tend to hang around and I need to clean up the library code a bit to address this problem. Nothing serious, just annoying (at least in my opinion).

I’ll do some additional posts in the coming day to clarify the code and its usage. Probably necessary as it is extremely flexible and can therefore be a bit hard to grasp at the start.

RewriteEngine on
RewriteBase /

# All Dutch language browsers redirect to index.html
RewriteCond %{HTTP:Accept-language} ^nl [NC]
RewriteRule ^$ /index.html [L,R=301]

# All non-Dutch browsers redirect to index_en.html
RewriteRule ^$ /index_en.html [L,R=301]

The RewriteBase directive makes sure the rewrite rule only triggers when accessing the root of the website, any subsequent request for a specific page will not trigger the rewrite rule.

First some constants that I use. You can rip them out if you don’t like them, they’re not essential, I just like using constants for this type of work.

/**
* Define the url path for the resources
*/
defined('INCLUDE_PATH') or define('INCLUDE_PATH', '/include');

/**
* Define the language using language code based on BCP 47 + RFC 4644,
* http://www.rfc-editor.org/rfc/bcp/bcp47.txt
*
* The language files can be found in directory 'lang'
*/
defined('LANGUAGE') or define('LANGUAGE', 'en-us');

The constants are used in the code below, replace them with your own values or approach where necessary. What happens is that a language file is loaded based on the configured language. A static array $translations is used to ensure that the language file is loaded once and every other subsequent call is handled through the $translations array in memory rather than reloading the language file. The language file is constructed in JSON format and when the language file is loaded into the $translations array the PHP json_decode function is used to convert from JSON to PHP associative array format. When a call is made to the function a language phrase is passed to the function and the matching value is found in the $translations array by using the language phrase as a key for the associative array.

/**
* Load the proper language file and return the translated phrase
*
* The language file is JSON encoded and returns an associative array
* Language filename is determined by BCP 47 + RFC 4646
* http://www.rfc-editor.org/rfc/bcp/bcp47.txt
*
* @param string $phrase The phrase that needs to be translated
* @return string
*/
function localize($phrase) {
    /* Static keyword is used to ensure the file is loaded only once */
    static $translations = NULL;
    /* If no instance of $translations has occured load the language file */
    if (is_null($translations)) {
        $lang_file = INCLUDE_FILE . '/lang/' . LANGUAGE . '.txt';
        if (!file_exists($lang_file)) {
            $lang_file = INCLUDE_FILE . '/lang/' . 'en-us.txt';
        }
        $lang_file_content = file_get_contents($lang_file);
        /* Load the language file as a JSON object and transform it into an associative array */
        $translations = json_decode($lang_file_content, true);
    }
    return $translations[$phrase];
}

An excerpt of the US English language file (in JSON format):

{
    "lang":"en-us",
    "No":"No",
    "Yes":"Yes",
    "or":"or",
    "Do you require help":"Do you require help"
}

An excerpt of the German language file:

{
    "lang":"de",
    "No":"Nein",
    "Yes":"Ja",
    "or":"oder",
    "Do you require help":"Brauchen Sie Hilfe"
}

An example of it’s usage:

print localize('Do you require help') . localize('Yes') . localize('or') . localize('No');

An example of usage in some of my own code:

$create_page_array = array(
    'status_message' => $status_message,
    'table_caption' => localize('Delete Operation'),
    'table_explanation' => localize('This command deletes an operation'),
    'table_content' => $table_content,
    'checkbox' => 'operation_name',
    'table_sort' => '[[1,0]]'
);

The advantages to me are:

1. Very easy integration into your code
2. The language phrases remain recognizable in your own code
3. The language files can be easily customised because the original phrase is part of the translation
4. Language file needs to be loaded only once
5. The language file is coded in an open standard (JSON) and can be processed in other ways that you currently don’t foresee

The controller receives input and initiates a response by making calls on model objects. An MVC application may be a collection of model/view/controller triplets, each responsible for a different UI element. MVC is often seen in web applications where the view is the HTML or XHTML generated by the app. The controller receives GET or POST input and decides what to do with it, handing over to domain objects (i.e. the model) that contain the business rules and know how to carry out specific tasks such as processing a new subscription.

People tend to think up very complex solutions for Front End Controllers in PHP. However the only thing a Front End Controller needs to do is act as a switchboard between view and model. It is also the part of the application that is most prone to attacks as you can manipulate URL’s and thereby attack or subvert the controller logic in giving you access to functions you’re not entitled to. For my NIST RBAC API PHP implementation I have made a simple and secure controller that I want to share. Code follows below:

If no action has been set the Default action will be called

$url_action = (empty($_REQUEST['action'])) ? 'Default' : $_REQUEST['action'];

Filter the GET/POST action parameter to allow only alphabetic characters because this is a main entry point to the program logic and therefore an interesting target for URL manipulation

if (!ctype_alpha($url_action)) {
    trigger_error('Action string has been tampered with, request terminated', E_USER_ERROR);
}

Check whether the action is set (it should be because it is filled with a default value anyway), then check whether the function exists by calling it and then call the function on behalf of the controller. Any error conditions are raised through trigger_error and the execution stops.

if (isset($url_action)) {
    if (is_callable($url_action)) {
        call_user_func($url_action);
    } else {
        trigger_error('Function does not exist, request terminated', E_USER_ERROR);
    }
} else {
    trigger_error('Function does not exist, request terminated', E_USER_ERROR);
}

End of the Front End Controller code. Subsequent code consists of view functions.

Complete code:

$url_action = (empty($_REQUEST['action'])) ? 'Default' : $_REQUEST['action'];
if (!ctype_alpha($url_action)) {
    trigger_error('Action string has been tampered with, request terminated', E_USER_ERROR);
}
if (isset($url_action)) {
    if (is_callable($url_action)) {
        call_user_func($url_action);
    } else {
        trigger_error('Function does not exist, request terminated', E_USER_ERROR);
    }
} else {
    trigger_error('Function does not exist, request terminated', E_USER_ERROR);
}

The controller checks whether the url_action consists of alphabetic characters, if so whether the function that is called exists and if the function exists it calls the function on behalf of the request. The function itself needs to check whether the user is entitled to accessing the function. This can be done through the NIST RBAC PHP API of which I will post later.

The names of the action need to be reflected in the function names, i.e. an ?action=AddUser will direct the user to function AddUser(). If this is undesirable you need to add a mapping table like:

$url_mapping = array('UrlAction' => 'NameoftheFunction' ...);

And you can then loop through that array and match up the url action with the proper function name.

The NIST RBAC model is a standardized definition of role based access control. Although originally developed by the National Institute of Standards and Technology, the standard was adopted and is copyrighted and distributed as INCITS 359-2004 by the International Committee for Information Technology Standards (INCITS).

In computer systems security, role-based access control (RBAC)[1][2] is an approach to restricting system access to authorized users. It is a newer alternative approach to mandatory access control (MAC) and discretionary access control (DAC). RBAC is sometimes referred to as role-based security.

Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions. Unlike context-based access control (CBAC), RBAC does not look at the message context (such as a connection’s source).

Since users are not assigned permissions directly, but only acquire them through their role (or roles), management of individual user rights becomes a matter of simply assigning appropriate roles to the user; this simplifies common operations, such as adding a user, or changing a user’s department.

The NIST RBAC Model uses a limited set of concepts to define an RBAC system as depicted below. The system has (1) users, users have (2) sessions and sessions and users have (3) roles assigned to them. Each role consist of (4) permissions and permissions are based on (5) objects and (6) operations.

Great though standards are they hardly ever give you concrete stuff like an actual implementation or a data model. As part of my series of little releases leading up to the release of the NIST RBAC PHP API I’m delivering a worked out RBAC Data Model based on the NIST standard. The model has been designed with an ERD tool named “Dezign for Databases” and it can generate the DDL code for just about any database. For the moment I’m releasing this in MySQL 5 format but if there are requests for other databases please let me know and I’ll update the post accordingly.

An Entity-Relationship diagram of the model is depicted below:

The model contains 6 main entities:

1. user: this contains all the user data
2. session: this contains the session data for all currently logged on users
3. role: this contains all the roles that are defined
4. permissions: this contains all the permissions based on objects and operations
5. object: objects are the items that require protection
6. operation: operations are the actions that are performed on the objects

As you can see the entities in the data model map on the entities shown in the NIST RBAC entity model. Because there are a fair number of many-to-many relationships in the model there are a number of bridge tables to help out:

1. user_session: this combines the user with an active session, i.e. which users of the set of all users are currently logged in As Alex pointed out in the comments below this is not a many-to-many relationship but a one-to-many relationship and therefore doens’t require a bridge table
2. user_role: this combines the user with any number of roles (but at least one)
3. session_role: when a user logs in all the assigned roles are associated with the session. This allows for temporary changes to the role structure, i.e. take away a role for the duration of the session or add a role for the duration of the session
4. role_permission: this associates a role with one or more permissions

The model is 4NF/5NF and fully relational. For MySQL usage it requires an InnoDB (or equivalent) database. I have only tested it myself with MySQL 5.0/5.1 and the InnoDB storage engine but there should be nothing in the DDL file that would conflict with other (transactional) storage engines. If you encounter problems with executing the file please let me know (don’t know if I can fix them but I’ll give it a try).

You can execute the code below as a SQL query, either directly in MySQL command line or via phpMyAdmin. Don’t forget to create a database, and select that database, before you execute the query!

# ---------------------------------------------------------------------- #
# Script generated with: DeZign for Databases v6.1.2                     #
# Target DBMS:           MySQL 5                                         #
# Project file:          rbac_nist_0_17.dez                              #
# Project name:          nist rbac model                                 #
# Author:                m.e. post                                       #
# Script type:           Database creation script                        #
# Created on:            2010-07-31 20:26                                #
# ---------------------------------------------------------------------- #

# ---------------------------------------------------------------------- #
# Tables                                                                 #
# ---------------------------------------------------------------------- #

# ---------------------------------------------------------------------- #
# Add table "user"                                                       #
# ---------------------------------------------------------------------- #

CREATE TABLE `user` (
 `user_id` INTEGER(8) NOT NULL AUTO_INCREMENT,
 `username` VARCHAR(40) NOT NULL,
 `password` VARCHAR(64) NOT NULL,
 `nonce` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
 `first_name` VARCHAR(50) NOT NULL,
 `family_name` VARCHAR(100) NOT NULL,
 `email` VARCHAR(100) NOT NULL,
 PRIMARY KEY (`user_id`)
)
 ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

# ---------------------------------------------------------------------- #
# Add table "role"                                                       #
# ---------------------------------------------------------------------- #

CREATE TABLE `role` (
 `role_id` INTEGER(8) NOT NULL AUTO_INCREMENT,
 `name` VARCHAR(100) NOT NULL,
 PRIMARY KEY (`role_id`)
)
 ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

# ---------------------------------------------------------------------- #
# Add table "user_role"                                                  #
# ---------------------------------------------------------------------- #

CREATE TABLE `user_role` (
 `user_id` INTEGER(8) NOT NULL,
 `role_id` INTEGER(8) NOT NULL,
 PRIMARY KEY (`user_id`, `role_id`)
)
 ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE INDEX `IDX_user_role_1` ON `user_role` (`user_id`);

CREATE INDEX `IDX_user_role_2` ON `user_role` (`role_id`);

# ---------------------------------------------------------------------- #
# Add table "session"                                                    #
# ---------------------------------------------------------------------- #

CREATE TABLE `session` (
 `session_id` INTEGER(8) NOT NULL AUTO_INCREMENT,
 `user_id` INTEGER(8) NOT NULL,
 `name` VARCHAR(64) NOT NULL,
 `created` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
 PRIMARY KEY (`session_id`, `user_id`)
)
 ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

# ---------------------------------------------------------------------- #
# Add table "operation"                                                  #
# ---------------------------------------------------------------------- #

CREATE TABLE `operation` (
 `operation_id` INTEGER(2) NOT NULL AUTO_INCREMENT,
 `name` VARCHAR(100) NOT NULL,
 `_create` TINYINT(1) DEFAULT NULL,
 `_read` TINYINT(1) DEFAULT NULL,
 `_update` TINYINT(1) DEFAULT NULL,
 `_delete` TINYINT(1) DEFAULT NULL,
 `locked` TINYINT(1) NOT NULL DEFAULT 0,
 PRIMARY KEY (`operation_id`)
)
 ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

# ---------------------------------------------------------------------- #
# Add table "object"                                                     #
# ---------------------------------------------------------------------- #

CREATE TABLE `object` (
 `object_id` INTEGER(8) NOT NULL AUTO_INCREMENT,
 `name` VARCHAR(100) NOT NULL,
 `locked` TINYINT(1) NOT NULL DEFAULT 0,
 PRIMARY KEY (`object_id`)
)
 ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

# ---------------------------------------------------------------------- #
# Add table "permission"                                                 #
# ---------------------------------------------------------------------- #

CREATE TABLE `permission` (
 `permission_id` INTEGER(8) NOT NULL AUTO_INCREMENT,
 `name` VARCHAR(100) NOT NULL,
 `object_id` INTEGER(8) NOT NULL,
 `operation_id` INTEGER(2) NOT NULL,
 PRIMARY KEY (`permission_id`, `name`, `object_id`, `operation_id`)
)
 ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 ;

CREATE INDEX `IDX_permission_1` ON `permission` (`object_id`);

CREATE INDEX `IDX_permission_2` ON `permission` (`operation_id`);

# ---------------------------------------------------------------------- #
# Add table "role_permission"                                            #
# ---------------------------------------------------------------------- #

CREATE TABLE `role_permission` (
 `role_id` INTEGER(8) NOT NULL,
 `permission_id` INTEGER(8) NOT NULL,
 PRIMARY KEY (`role_id`, `permission_id`)
)
 ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE INDEX `IDX_role_permission_1` ON `role_permission` (`role_id`);

CREATE INDEX `IDX_role_permission_2` ON `role_permission` (`permission_id`);

# ---------------------------------------------------------------------- #
# Add table "session_role"                                               #
# ---------------------------------------------------------------------- #

CREATE TABLE `session_role` (
 `role_id` INTEGER(8) NOT NULL,
 `session_id` INTEGER(8) NOT NULL,
 `user_id` INTEGER(8) NOT NULL,
 PRIMARY KEY (`role_id`, `session_id`, `user_id`)
)
 ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE INDEX `IDX_session_role_1` ON `session_role` (`role_id`);

CREATE INDEX `IDX_session_role_2` ON `session_role` (`session_id`);

# ---------------------------------------------------------------------- #
# Foreign key constraints                                                #
# ---------------------------------------------------------------------- #

ALTER TABLE `user_role` ADD CONSTRAINT `user_user_role`
 FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `user_role` ADD CONSTRAINT `role_user_role`
 FOREIGN KEY (`role_id`) REFERENCES `role` (`role_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `session` ADD CONSTRAINT `user_session`
 FOREIGN KEY (`user_id`) REFERENCES `user` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `permission` ADD CONSTRAINT `object_permission`
 FOREIGN KEY (`object_id`) REFERENCES `object` (`object_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `permission` ADD CONSTRAINT `operation_permission`
 FOREIGN KEY (`operation_id`) REFERENCES `operation` (`operation_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `role_permission` ADD CONSTRAINT `role_role_permission`
 FOREIGN KEY (`role_id`) REFERENCES `role` (`role_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `role_permission` ADD CONSTRAINT `permission_role_permission`
 FOREIGN KEY (`permission_id`) REFERENCES `permission` (`permission_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `session_role` ADD CONSTRAINT `role_session_role`
 FOREIGN KEY (`role_id`) REFERENCES `role` (`role_id`) ON DELETE CASCADE ON UPDATE CASCADE;

ALTER TABLE `session_role` ADD CONSTRAINT `session_session_role`
 FOREIGN KEY (`session_id`, `user_id`) REFERENCES `session` (`session_id`,`user_id`) ON DELETE CASCADE ON UPDATE CASCADE;

MEDIA_URL = 'media.example.com'

In NGINX:

server {
  listen 80;
  server_name media.example.com;
  location {
    root /PATH/TO/MEDIA/FILES;
  }
}

That’s it, very easy. Oh please replace the media.example.com with your own URL of course.

The best place to start with these challenges is to read the appropriate standard to learn what the original implementers had in mind with their solution. The standard for Basic Authentication is RFC 2617. The standard states:

The realm directive (case-insensitive) is required for all authentication schemes that issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (the absoluteURI for the server whose abs_path is empty; see section 5.1.2 of [2]) of the server being accessed, defines the protection space.

So there’s two items that define the Basic Authentication protection space:

• realm: a server provided, unique string identifier
• abs_path: the url

By making both items unique and changing them at log out time you basically break the basic authentication protection space and effectively log out the user.

The solution requires the use of mod_rewrite to direct traffic for non-existent resources to the index.php file. Please place a .htaccess file with the following contents in the folder that you wish to protect:

.htaccess:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [NC,L]

Place an index.php file in the same folder (/auth in this example) with the following content:

<?php

session_start();

if (empty($_SESSION['session_id'])) {
    session_regenerate_id();
    $_SESSION['session_id'] = session_id();
    header("Location: /auth/" . $_SESSION['session_id'] . "/", TRUE, 301);
}

$url_action = (empty($_REQUEST['action'])) ? 'HomePage' : $_REQUEST['action'];
if (isset($url_action)) {
    if (is_callable($url_action)) {
        call_user_func($url_action);
    } else {
        print 'Function does not exist, request terminated';
    }
}

function HomePage() {
    print '<h1>Homepage</h1>';
    print '<p><a href="?action=LogIn">LogIn</a></p>;
    print '<p><a href="?action=LogOut">LogOut</a></p>';
    print '<p><a href="?action=SecureContent">Secure Content</a></p>';
}

function LogIn($url='') {
    $session_id = $_SESSION['session_id'];
    while (!IsAuthenticated()) {
        header('WWW-Authenticate: Basic realm="' . $session_id . '"');
        header('HTTP/1.1 401 Unauthorized');
        die('Authorization Required');
    }
    if (!empty($url)) {
        return TRUE;
    } else {
        header("Location: /auth/" . $_SESSION['session_id'] . "/", TRUE, 301);
    }
}	

function LogOut() {
    session_destroy();
    session_unset($_SESSION['session_id']);
    header("Location: /auth/", TRUE, 301);
}

function SecureContent() {
    if (LogIn("SecureContent")) {
        print '<h1>Secure Content</h1>';
        print '<p>This is secure content</p>';
        print '<p><a href="/auth/' . $_SESSION['session_id'] . '/?action=HomePage">Home Page</a></p>';
    } else {
        print '<h1>Not Authorized</h1>';
    }
}

function IsAuthenticated() {
    if (isset($_SERVER['PHP_AUTH_USER']) && isset($_SERVER['PHP_AUTH_PW'])) {
        $httpd_username = filter_var($_SERVER['PHP_AUTH_USER'], FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_HIGH|FILTER_FLAG_ENCODE_LOW);
        $httpd_password = filter_var($_SERVER['PHP_AUTH_PW'], FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_HIGH|FILTER_FLAG_ENCODE_LOW);
        if ($httpd_username == "test" && $httpd_password == "test") {
            return TRUE;
        } else {
            return FALSE;
        }
    }
    return FALSE;
}

?>

Both files need to be put in a folder named /auth for these examples to work. You can change the folder name in the index.php example to suit your own environment.

A the start of the script a unique id is generated through PHP session mechanism and this session id is inserted into the url (hence the requirement for mod_rewrite to catch these urls). A redirect takes place to this new url and the homepage is shown. If you click on login a 401 header is generated using a realm that uses the same session id. If you click logout the current session id is destroyed and you are redirected to the start of the script where a new session id is generated. If you click on a protected item without a login the login function is called.

It’s been an ok experience so far, I miss my Atom/XSLT solution mainly because I was quite pleased with my own inventiveness but after the annoying experience with IE8 rendering my client side XSLT solution useless most of the fun went out of that any way.

The WordPress templating is quite horrible, about the worst that PHP is capable of, hopefully that will improve somewhat in the near future although I won’t get my hope up.

The plugins works fine, it took me a while to figure out not to hack the javascript stuff directly into the templates or posts but rather download the appropriate plugin like the SyntaxHighLighter and use custom tag constructions in the post that don’t get filtered out by WordPress.

Still need to do some tweaking on the template, it’s getting there but some improvements to the right column spacing need to be done. I’ll probably drop the left column so there’s more space for the blog posts, the code fragments seem a bit too constrained at the moment.

I’ve gone back to XHTML 1.0 Strict rather than follow the fashionable crowd with HTML 4.01 Strict or HTML 5. I remain convinced that there’s nothing wrong with XHTML 1.0 Strict and I like the fact that I can process it as XML when I need to.

Alas these happy years are now over due too Internet Explorer 8. For reasons unknown (and undocumented) IE8 no longer respects the 512 bytes of crud workaround and insists on deploying its “friendly” feed view on everything it perceives as being a feed, client side XSLT and 512 bytes workaround be damned.

Given the potential audience for IE8 I can’t go on with my favoured method and I have decided to switch to a server side XSLT rendering. Given the high level of standardisation available within XSLT I didn’t have to change a single item in my stylesheet.

Whilst on the experimental track I took some time to play around with typeface.js and Cufón. I had already used SIFR on this site and I was interested in how it would compare against these newcomers. Both typeface.js and Cufón are completely javascript based solutions that embed their fonts as javascript files in the page. Getting both libraries to work required a bit of tinkering to acquire a feel for their approach but basically all examples and code where up and running in minutes. There’s not much difference in how both libraries work, they both use javascript with a combination of <canvas> or VML elements. From an aesthetic viewpoint I like Cufón better because the fonts seem crisper than those of typeface.js. This might have something to do with the extensive font rendering process that was created for Cufón. I set the <h1> and <h2> in Cufón and I like the results enough to abandon SIFR. I even tried to set an entire page in Cufón but that to all kinds of amazing behaviour within FireFox (even crashing it) so I decided to let that approach rest. It did however get me started on looking in/back to CSS 3 font-face adoption which seems to be imminent for the large browsers with Safari 3.1 already implementing it. For those of you that use Safari 3.1 (or are using a browser that supports font-face now) I have set the paragraphs in Delicious Roman, a free font from Jos Buivenga.

Oh by the way the server side XSLT rendering is done with PHP. All requests for XML files are forwarded by Apache based on a specific AddHandler and Action.

# Handler atom_xslt is associated with xml files
AddHandler atom_xslt xml

# Subsequently handler atom_xslt is associated with index.php
# for actual processing
Action atom_xslt /index.php 

# Force everything to the feed
DirectoryIndex index.xml

A simple caching mechanism is applied by the PHP script to render to HTML once and only update the rendered file after either the XML feed or the XSLT stylesheet have been update. Now that I don’t apply a client side XSLT anymore there’s no reason to stick with XHTML anymore and I have switched to HTML 4.01 Strict.