Latest News

Submitted for your approval is a Terrible, Old Manse. This is my first attempt at making an interactive fiction game with Inform 7. The game is an interpretation of the classic Atari 2600 game Haunted House.

As you play the game, please do send me a list of typos or weird behavior that you find. It is easy enough to bang out new releases.

Enjoy!

Joe's Own American-style Potato Salad

Cook time: 30 minutes + 8 hours of "get happy time" in the refrigerator

Software

• Vegetables:
  • 2lb of red potato (or an equal mix of red/yellow)
  • 1 small (not pearl) onion (any color)
  • 1-2 shallots
• Dressing:
  • 1/4 cup (or as needed) of mayo
  • 1 tbsp of spicy mustard
  • 1 tsp of Worcestershire source
  • 1 tbsp of lemon juice
  • 1/2 tsp of apple cider vinegar
  • A small handle of fresh chopped parsley
• Other:
  • salt and pepper
  • cooking oil (olive oil or a neutral oil is fine)

Preparation

If desired, peal potatoes. Cut potatoes into bite-sized chunks. In a large pot deposit potatoes, several good sized pinches of salt and enough water to just cover the spuds.

Bring to a boil and then back the heat down to medium (you want active boiling (more than a simmer), but not a violent rolling boil). Cook until fork tender (10-15 minutes).

Dump spuds into a colander and hose down with cold water. Do not drown them.

Dice the onion and shallots. In skillet, add a tbsp of cooking oil and turn the heat to low. Add onions, shallots and a pinch of salt. Sweat the aromatics for about 10 minutes. Remove from heat when onions are translucent. Do not burn or caramelize onions.

In a large mixing bowl, add the dressing ingredients. Mix until smooth.

When the potatoes and aromatics are coolish, add to dressing. Fold in the vegetables carefully so as not to destroy the spuds. Add salt and pepper to taste and yes, you have to taste it to know.

Refrigerate overnight. Serve chilled for best results.

NOTE: The full code archive of mechanism described below can be found here

Joomla is a PHP-based CMS that enjoys wide-spread popularity. It's got a many built-in features that make it great for blogs and news-oriented sites right out of the gate. Additionally, it supports three kinds of extension mechanism: components, plugins and modules. Components are low-level facilities that generally support the other two. Modules are often user-visible blocks of HTML that can be selectively added to the page users see. Plugins respond to various events (page rendering, authentication requests, etc) generated by the Joomla application.

Joomla comes with a variety of login plugins that all use the login module. These plugins allow users to be validated against an external authentication mechanism like LDAP or GMail.

Sometimes it is desirable to log users into the Joomla system who have already been authenticated by a different system without asking for their credentials again. This is called signle sign-on (SSO). SSO is a very important usability and security feature of many Service-Oriented Architectures (SOA). In this article, I will present a token-based mechanism for creating SSO to joomla using the standard extension methods.

To understand this problem a bit better, it is critical to realize that there are two seperate notions of identity in an SSO schema. There is the previously authorized identity (that is, the identity that the user supplied to the non-Joomla system that originally authenticated them) and the user account on the Joomla system that is stored in the local users table. One of the challenges of SSO is to map the remote identity to the local one. For the sake of this excerise, let's assume that the usernames in both the remote authentication system and the local Joomla one are the same.

The next problem is to create a protocol by which authentication credentials may be passed from the remote system to the local Joomla one. To accomplish this, I choose to use to copy the existing mod_login form and make some minor adjustments to accept HTTP GET parameters. These GET parameters are translated into values in a form that can be processed by the default user compoent. Since the user component calls out the enabled authentication plugins, this the kind of routing is desirable.

This form really needs three bits of information to authorize a user: the username, the session token and a checksum. The username is self-evident. The session token is provided to all authenicated requestors and is discussed more later. The check sum is hash of the username, token and a shared secret known to this system and the remote system passing users to it. More on this later too.

Using a bit of javascript magic, this hidden form is submitted automatically.

Of course, a custom authentication plugin is also required. The plugin needs to read a few of the custom form values that are not passed in through the normal onAuthenticate() call, so it is necessary for the plugin to directly read from the superglobal $_POST. The job of this plugin is very simple. If the token is valid (that is, it can be found in a DB table and is younger than 4 hours) and the hash value of the username, token and shared secret matches the given hash, then the user is authenticated. The user is found in the local system and the response object is populated accordingly.

The session token can be any string identifier. In this case, it is the MD5 hash of the value returned by the PHP built-in uniqid(). This value is generated by a script called 'session.php'. The script generates this value, stuffs it into a DB table and simply echoes the value to the caller.

The key to the security of this system comes from the secret string known only to the remote system that wishes to pass users to the local Joomla system and authentication plugin. This secret is used to generate a hash of the usernam and the session token. By using a hashing mechanism like MD5 or SHA1, this checksum value provides pretty good assurance that the values passed in were from a known and trusted source.

The way the remote system and the Joomla system interact to make this autologin happen is the follow:

• The remote client calls the session.php script on the local Joomla system
• The remote client hashes the session token, username and secret
• The remote client generates a URL to the local Joomla system's homepage that passes in the following GET parameters: u, t, s (for username, token and checksum respectively)
• The remote client redirects the user to this URL
• If the token is authenticated, the user is logged into the local Joomla system as a local Joomla user.

You'll also notice that you could easily map all remote users to one generic Joomla user if that is desirable.

I hope you find this useful in crafting your own Joomla solutions

French Onion Dip

Software:

• 1 cup of white or yellow onions
• 4oz. of beef broth
• 1 good-sized garlic clove
• 16oz of sour cream
• 1 teaspoon of Worcerstershire sauce
• Extra vigin olive oil
• salt + white pepper (black pepper is fine too)

Preparation:

Dice the onions fine. No one wants huge chunks of onions hanging off their potato chips.

Smash and chop the garlic.

Put a non-iron skillet pan over lowish heat. More heat than for a sweat but far less than for a saute. When the pan is hot, add a puddle of oil to the pan. How much? Enough to cover the bottom of the pan, but not more. This isn't a deep fry.

Add the onions and garlic to the pan. Throw a pinch of salt on to the veggies. Let 'em sit there for 20 minutes. You're caramelizing the onions. Give them a stir ever minute or two so that you don't burn them.

When the onions are golden brown and delicious, move them to the sides of pan. Deglaze the pan with the beef broth. Pour the liquid into the pan and using a wooden spoon, scrap up the frond from the pan. Did you notice that the onions sucked up the broth? That's the secret.

Remove the onion/garlic mass to bowl for cooling. I recommend a glass bowl for this, but whatever you use will not affect the final taste.

If you added 1/4 teaspoon of garlic powder, you wouldn't ruin the dip.

Slop into a mixing bowl the sour cream and the worcestershire sauce. Stir until mixed.

When the onion/garlic mass is cool enough to touch, add to the sour cream. If you add the hot mass to the cream, it could curdle.

Add salt and pepper to taste. Do not over salt, especially if you're planning on serving this with potato chips. And I recommend serving this with potato chips.

I suspect that adding an ounce or two of brandy or cognac at the deglazing stage would be the right thing to do, if you've got such things on hand.

Some people will want to replace up to 6 oz of the sour cream with mayo. I think this makes dip too runny, but it is your food to play with.

Serving options:

With potato chips (Cape Cod chips are my favorite) or with a veggie assortment (e.g. carrots and celery).

I've been working with the PHP CMS WordPress a lot lately. It's a pretty simple system that doesn't make its internals hard to get to, which I appreciate.

One of the internal functions WP provides is wp_mail. This, you might have guessed, is used to send SMTP mail. The parameter list for this function is a bit long and long parameters lists are hard to remember:

wp_mail( $to, $sub, $body, $hdrs, $attach );

These parameters are pretty self-evident: mail recepient, subject line, body of message, SMTP headers, attachments. The last two parameters are optional. This works great for sending plain, unformated text messages. However, you may want to tweak this a bit.

The first thing you might want to do is change the default sender. This is done by adding a header:

$to = "nemo@uptopia.com";
$sub = "Your submarine parts";
$msg = "I have the new parts for your fabulous machine.";

$headers = array("From: Joe Johnston <jjohn@taskboy.com>");
$h = implode("\r\n",$headers) . "\r\n";

wp_mail($to, $sub, $msg, $h);

This makes the email look like it was sent by me even though the the web server process running the PHP script isn't owned by my account.

Another common task is to send HTML-formated email using this system. To do this, you must change the content type of the message to text/html. This is most easily done through the headers, even though you are supposed to be able to do this through the filter wp_mail_content_type. In my testing, this did not work, but the following code did:

$to = "nemo@uptopia.com";
$sub = "Your submarine parts";
$msg = "<html><body><h1>Awsome news</h1>
    <p>I have the new parts for your fabulous machine.</p>
    <address>--Joe</address>";

$headers = array("From: Joe Johnston <jjohn@taskboy.com>",
	         "Content-Type: text/html"
	         );
$h = implode("\r\n",$headers) . "\r\n";

wp_mail($to, $sub, $msg, $h);

By adding the content type to the headers, the recipient's email client should format the message accordingly.

Of course, sending HTML email has risks. It could be caught in spam filters. The client may not support HTML formatting (although that's rare). The client may disable email HTML from using javascript, CSS or grabbing remote assets like images.

Caveat Spammer.