melbourne chapter

I needed to install an manage some ODT files today that I have created with my Windows StarOffice (another alternative to Microsoft Word provided by Sun for much much less [and based on openoffice]) on my Mac OSX. OpenOffice is multiplatform and compatible with all other major office suites and is available and distributable for free. Considering the pricing of Microsoft Office today, it is an extremely feasible alternative. If your clients send you files it will still be perfectly compatible to open, edit and send back.

View the Open Office website here.

A Note for Mac OS-X Intel users: X11 required

You will need to ensure you do not download the PPC version as it will not run on your Intel chipset. Get the Intel Chipset builds from here.
On my mac which is running on the new Intel core chipset, you will need to install X11. Information on X11 can be found on Apples website, but you are able to install it from your original Mac OSX Installation CD. To do this follow this guide to getting the X11 user package installed:

1. Insert the Mac OS-X Installation CD
2. Goto the Finder
3. Hit the “Go” Menu -> “Go to Folder” -> Type “System” -> Browse “Installation” -> Browse “Packages” -> Find and execute “X11User.pkg”

Last year I worked on a website called Living Edge which sell classic furniture by great designers (such as Ray and Charles Eames, Charles Wilson, Norman and Quaine, George Nelson, Bill Stumpf) and brands (Herman Miller, Emeco, Walter Knoll and the like).

The project was based off a custom written content management database that allowed the Living Edge staff to maintain every aspect of their online product catalog online, such as creating designers, manfacturers, categories, products, galleries and work with PDF and CAD attachments to create a rich useful interface to their A’n'd (architects and designers).

As a core requirement to the project we had to consider an implementation of a search engine which would allow architects and designers to choose their preferred way of browsing a catalog (such as via their favourite designer or brand, or look under particular categories to find inspiration). With this in mind and with LivingEdge providing such a comprehensive product catalog, I implemented a series of AJAX based Drilldown Menus.

The AJAX technology was fairly new to me at the time, but was fastly becomming respected as the direction for creating powerful HTML interfaces. I chose AJAX because we could quickly drill down through the product catalog without requiring refreshes or mass data to be sent to the clients browser. It also was a way for us to limit the possibility of users choosing combinations that did not exist and result in “zero” matches.

Overall we were able to provide real-time indications of how many results would be returned for each combination and indicate beside each option. We could also remove options and guide the user quite quickly. Users could start anywhere across the dropdowns and only place in as much information as they like.

I implemented the solution using PHP to query my relational database, and built XML WDDX packets to translate the information (in a datastructure) to the front-end clients JavaScript API. I used a simple framework called SAJAX as a basis for handling my HTTP XML Requests. I also created a server-side proxy which would instantly return packets based on the criteria parsed to the server through the request to dramatically reduce load and execution times of queries. Overall it was very very snappy.

The client was very happy with how the search engine worked, and has sparked a “revamp” of several of its competitor websites. LivingEdge were able to raise the bar and provide a very quick and useful resource for their visitors to use.

Visit the Living-Edge site here.
(Interface Design, Flash and Graphics by Sacha Jerrems)

You can learn more about AJAX and AJAX design patterns online by checking out the very useful resource: http://www.ajaxpatterns.org/ or view information about SAJAX here. You can learn about distributed data exchanges on WDDX here.

ANZ EGate Merchants will feel the pinch today after the MIGS Payment Server failed at 9.30 this morning. ANZ, who say the issue is a link with Mastercard, failed to adequately alert merchants to the problem and as result have has left many online store fronts to deal with failed credit card transactions and irrate customers.

Are ANZ dropping their game? This event follows on from a recent bungle with a ANZ MasterCard tape which as a result lead to a duplication of over 400,000 transactions Australia wide.

We met yesterday to set the direction for Melbourne Chapter blog for the next 3-6 months. We will be restructuring the categories and finally getting a new design and interface. We are eager to start implementing some of these changes and start posting our ideas across several new topics. Please keep checking back to see the changes we implement.

Often you need to create some way to display a message over the top of the current screen. This can be things like disclaimers or popup windows with ads in them etc. Instead of running into problems with using JavaScript window.open() events and Popup blockers you can use simple JavaScript and CSS properties to create an internal popup window or note infront of your HTML.

The possible uses of this are:

- Dynamic Notes or Messages, such as better presentation of Error Messages from Form Validation
- Popup Disclaimer over content that are hidden once the user hits “I agree”
- Displaying promotional material, such as a Flash advertisement

Typically using DHTML we are using JavaScript to change the properties of elements of a webpage. Each element appearing on a website has certain values which we can change dynamically based on events such as an onclick or hitting submit on a form.

Simple panel window over HTML content

The simplest example of a internal “popup” window that sits above the text. To do this we take advantage of the HTML element DIV. This element is a block-level element that by default does not contain any presentation attributes, like border, padding, margin or background. DIV’s have been widely accepted as the element to use when creating your HTML layout because of their flexibility and compliance with Content/Design seperation.

To create our simplest popup window we will apply some CSS-styles to the DIV element.

Z-Index (view w3c reference)
Z-Index terms to the layering of content. By default your HTML contents are placed at position 0. Imagine this as glass panes you look through on your computer screen. By assigning a element a Z-Index of 1 it creates another pane ontop of the original and it will sit cleanly over the elements at position 0.

Position (view w3c reference)
Position allows you to manage the location of where to place your popup window. You can use different attribute values like relative, absolute etc that allow you to position a DIV on your screen.

Visibility (view w3c reference)
The visibility property allows us to hide or display your HTML elements, in this case the DIV.

The CSS styles can be assigned into two classes that represent the states of your DIV; visible and hidden. Your DIV can then switch states by switching which style class is applied. We can do this by locating the element in the HTML document through the DOM (Document-Object-Model). To locate the object easiest we apply a unique ID to the DIV element (view w3c reference - Element identifiers: the id and class selector) and we can then use JavaScript to update the DIV elements class to represent its state.

Controlling a elements CSS property in JavaScript:

object = document.getElementById(’elementId’);
The JavaScript method ‘getElementById’ allows us to locate an element and gain a reference to it. Once we have a reference to this element we can access the properties of that attribute.

object.className = “cssClass”;
The property ‘className’ refers to the current classes applied to the element. It will start off containing the contents of the elements ‘class’ attribute. We can update this property to the name of the CSS class that represents the state of our DIV (eg. visible and hidden).

Popup Notification Window

An alternative method to displaying messages from JavaScript would be to mix what we have learnt with controlling CSS states with JavaScript and introducing dynamic creation of the DIV contents. This way when we wish to display the a notification or alert, we can generate the HTML contents into a DIV and then switch the CSS property to represent its value.

Making use of the following JavaScript functions are useful in achieving popup notifications:

object.innerHTML = “Hello World”;
This allows us a fast way to quickly create HTML content into an element (instead of creating new objects and attaching VIA the DOM model - this method is faster as tested here). Once we locate our element (using getElementById) we can then change the contents by applying it to the innerHTML property of the object.

We could then create our own version of the javascript:alert(msg) function to display a nicely formatted popup notification.

function notifyMsg(id,msg) {
// Locate and update our popup window
object = document.getElementById(id);
object.innerHTML = msg; // We could also create some HTML to prepend our message
// Add our additional options such as OK
object.innerHTML += ‘whatever such as a close button who uses javascript to switch the state of this element to hidden’;
// Change the CSS state to visible
object.className = ‘visibleNotifyMsg’;
}

Usability of the Window

We have to consider certain affordance with the popup window, to ensure that the window is dealt with smoothly and intiuitively without causing a great hick-up to the user. Using a “X - Close” in the top right handle of your window will help create a quick way for people to close the message. Also a button at the bottom or image saying Close Window may prove useful as well.

You will also need to ensure that there is enough contrast created through the use of Borders or Background Colour that helps differentiate it from the content it is sitting upon. A white popup window with black text sitting over white background with black text will loose your user. If there is some sort of action required, consider the use of Colours to help your user identify the action required, eg. If poping up a Validation Alert, consider using Red Text or a Red Cross icon at the top of your message.

Click here to view the HTML Example file

I have updated my recent post on sharing session across domains. I will post my source code once it is a bit better documented using a centralised issuing server.
View the article Sharing a session across multiple domains/servers with PHP here.

Something that we have to be careful to consider is hackers generating a Form and remotely sending form input to your website. eg.

1. Hacker creates a form that has the same variables as your website form, and sets the action to your websites form action;
2. Hacker hits submit to inject in values to your form; such as malicious code or generating a script that automatically inserts data

Although we learn never to trust information sent to us in a form and checking the submitted values to be valid, we will also want to consider the origin of the forms submission [Cross-Site Request Forgeries (CSRF)]. Our Environment variables allow us to check a variable called HTTP-REFERRER but this can be easily changed by the hacker. So instead we will need to consider ways to ensure the form originated from our website (and only issued once).

I have done a little research into ways and Chris Shifflet recommends a token placed into the form and applied to the users session. This method can prove a very useful method of identifying whether a form had been “issued” from your website. His example of a useful way to help limit the occurance of this issue:

<?php
$token = md5(uniqid(rand(), true));
$_SESSION[‘token’] = $token;
$_SESSION[‘token_timestamp’] = time();
?>


<form action=”/add_post.php” method=”post”>
<input type=”hidden” name=”token” value=”<?php echo $token; ?>” />
Subject: <input type=”text” name=”post_subject” />
Message: <textarea name=”post_message”></textarea>
<input type=”submit” value=”Add Post” />
</form>

Chris’s recommendation supplies quite a good method of forcing the use of your own HTML forms, but is linear in nature (one form with one submit). For this to be more rock solid we need to consider implementation issues we always face as Web Developers: Multiple Windows and the Back Button.

We can make some more modifications to the script by including a 2D array of issued form tokens, and individually identify the Form with the corresponding Token:

<?php
$formId = md5(uniqid(rand(), true));
$token = md5(uniqid(rand(), true));

$_SESSION[‘formTokens’][$formId][‘token’] = $token;
$_SESSION[‘formTokens’][$formId][‘token_timestamp’] = time();
?>

<form action=”/add_post.php” method=”post”>
<input type=”hidden” name=”formId” value=”<?php echo $formId; ?>” />
<input type=”hidden” name=”token” value=”<?php echo $token; ?>” />
Subject: <input type=”text” name=”post_subject” />
Message: <textarea name=”post_message”></textarea>
<input type=”submit” value=”Add Post” />
</form>

We now are able to uniquely identify the valid token based on a unique form ID, with its own timeout values etc. This will allow us to cater for multiple windows or use of the back button across our forms.

Big News: Microsoft Founder and CEO Bill Gates will step down from his fulltime role in the Software giant in 2008.

“Our business and technical leadership has never been stronger, and Microsoft is well positioned for success in the years ahead. I feel very fortunate to have such great technical leaders like Ray and Craig at the company,” Says Gates who  plans to spend more time working at his foundation on global health and education initiatives.

“I remain fully committed and full time at Microsoft through June 2008 and will be working side by side with Ray and Craig to ensure that a smooth transition occurs.”

Source Australian IT http://australianit.news.com.au/articles/0,7204,19486936%5E15306%5E%5Enbv%5E,00.html

Updated 15 June 2007: I have provided the source code to this and a working example of sharing a session across unique domains here.

In-light of a recent project I have had to consider a strategy from diverting a user from an non-SSL server running to a different domain running SSL, and keep the same session. This would involve keeping the user who is signed in on the first server with a session cart selection being somehow shared to the next server. It also requires that the user have a single sign-in between several different domains.

Get your sessions into a database
To consider the sharing of information between different domains where they are potentially run by different users or servers, we would need to place the session information directly into a database that is able to be read in by each domain.

To get your sessions into a database, we could:
- Gain control of the Session with a PHP SessionWrapper using a Singleton
- Overwrite the main _open, _read, _write, _close, _destroy and _gc methods to persist to a common datasource (MySQL database)
- Create a _sessionInit method that checks for a PHPSESSID from the Request, if not checks the Cookie for a PHPSESSID
- Create the session with the ID present (if one)

My database table (session) would form:
- sessionkey varchar(32)
- data text
- expiry timestamp

This will securely conform with ownership issues in PHP Safe Mode as the session data will not be written to disk under each web user, it will be written to a common secure database accessible by other websites (with the correct username/password etc). Once again as you will be now taking over some of the security of a session you could read on ways of encrypting the information stored in the database for further security. You will simply need to add methods of encrypting the information (either with Symetrical or Assymetrical keys) in your _read and _write methods of your Session Wrapper.

* Note: I would recommend that you don’t store sensitive information in your session as by default it will be serialised in clear text to your datastore. Anyone capable accessing your session information will be able to see the details (such as CC details etc).

Updated 21 June 2006: Zend provide a good Code Gallery spotlight that gives a good example of a custom session handler to MySQL Database. You can read their article here.

Sharing the Session ID between sites
When diverting the user to the Secure server they would be parsed over using a URL containing the current PHPSESSID to resume on the next hosting service. If they end up at the website without travelling through a URL with PHPSESSID we can attempt to gain it from the user VIA the cookie (if present this is done automatically by PHP). But how can we ensure the user isn’t starting new sessions?

Centralised Issuing Session ID Server
So we have centralised our Sessions and made them available across multiple domains, but how can we further further ensure that the user holds onto the same Session ID? As there is not always clear sever points between the applications, parsing the Session ID in the URL might not be always as easy to track. Even if we searched through all links and applied the PHPSESSID in the URL - a user may decide to type in a domain directly to switch to the different server.

Unfortunately Cookies can not be shared across different domains (* although they can be across subdomains), so we cannot simply keep track of a session ID via a cookie.

A way to backup remedy to this would be to involve a Session ID issuing server that you can bounce a visitor off when creating an initial visit. The user is returned to the site URL they were requesting but after having a centralised Session ID inserted into their request. Also, if for some reason you wish to not reveal the Session ID in the bounce you could simply place in a retrieve_key that looks up the Session ID once the user is returned to their previous URL. You would also need to assign to the session a unique variable that indicated the session was “issued” and is not created by itself.

Using this central session ID manager as a fall back we could help eliminate those cases when the user shows up at a different domain and starting a new session ID. In some cases you may even be able to eliminate the requirement of parsing PHPSESSID in the URLs.

You will need to consider the security implications of handling sessions this way. If you need to regenerate a session ID it must be done with the Centralised Issuing server otherwise you will either loose the information in your session or start dual sessions that are not shared.

In most cases we will try to use the SSL server as the centralised issuing server and all secure steps can be processed under this URL. We can destoy the session on this server and start a new session. It will automatically cause the other domains to try and retrieve a new key (as long as we assign to the session a unique variable that indicated the session was issued, as when the session can’t be resumed on the other domains, they will realise they have to get a new session ID from the centralised server).

JavaScript provides us with a simple solution for form validation. Being completely client-side means that we can validate user data before we even make a request to the server, saving unnecessary load on the server. We can also prompt the user with dialogs in the form of alert and confirmation boxes. JavaScript isn’t without its disadvantages though. The biggest issue with JavaScript is that end-users must have active-scripting (JavaScript) enabled in their browsers. While a majority of browsers are JavaScript enabled by default, IE 6 Service Pack 2 users and those with 3rd Party Script blockers in Firefox will be alerted, and as a result paranoid users may choose to disable active-scripting on your web page.

Let’s take a look at a simple example of some JavaScript validation:

Line by line…

In the form creation we use the JavaScript onsubmit() function, which fires when a form element receives a request to submit. In this case I have used it to call my form validation function validate(), passing a relative reference to the form. Note the

return

statement. This is used to return the result of our validation to decide whether we send the request or not (i.e. a value of false will abort the request).

function validate(form) {

Since we passed a relative reference we can now reference all our form values via

form.<field>.value</field>

. Alternatively you could always store a reference to the form in a local variable, but passing but reference makes much more sense.

errStack = new Array();

Here I create an array to store my error messages. You can always concatenate a string of error messages and use a boolean variable to flag errors, however using an array means we can store a message, and then later check the length of this array to see if we have any error messages.

if (form.first_name.value == “”) {
errStack.push(”Please enter your first name”);

}

As mentioned above passing the relative reference to the form means we can now reference form elements using the relative reference of

form.field.value

. Here I check the value of the first_name field is not empty. If the value is empty I then “push” and error message into my errors stack errStack.

if (errStack.length > 0) {
alert(errStack.join(”\n”));

return false;
}

Following our field checks we have a final if() statement to check the length of our errors stack errStack. If the stack is longer than zero we have error messages that need to be reported to the screen. To do this we join all our error messages, delimited by the \n escape character so that each message is printed on a newline within the alert() box. Finally we return

false

which in turn aborts the form request.

return true;
}

On the other hand if the form passes all our checks we return

true

That was easy wasn’t it?

By no means is this the only way to validate a form using JavaScript but hopefully it provides you with an idea. For more references to JavaScript, and JavaScript validation I recommend visiting the W3Schools website.