Posts from — April 2009

The following are 5 javascript apps that I thought would never be possible. They are all written using the canvas HTML element.

The canvas element is a third party extension that allows for dynamic rendering of scriptable bitmap images.

It was initially introduced by Apple or use inside their own Mac OS X Webkit component, powering applications like Dashboard widgets and the Safari browser. Later, it was adopted by Gecko browsers (notably Mozilla and Firefox) and standardized by the WHATWG on new proposed specifications for next generation web technologies. Support is also present in the Opera 9.0 browser. Novell manufactures an XForms processor plugin for Internet Explorer, which also provides support for the canvas element. Independent efforts to support the canvas feature on Internet Explorer do not require plugins and are based solely on VML and Google has also begun a project to add canvas abilities to Internet Explorer using the same techniques.

Canvas consists of a drawable region defined in HTML code with height and width attributes. JavaScript code may access the area through a full set of drawing functions similar to other common 2D APIs, thus allowing for dynamically generated graphics. Some anticipated uses of the canvas include building graphs, animations, and image composition. Source

Note: Most of these examples are *not* compatible with Internet Explorer

1) Canvascape

A proof of concept of a 3D FPS. There is a textured and non-textured version available.

2) MSX Emulator

This project shows us the true power of javascript and the canvas element. It is an MSX emulator, which includes the ability to load and play game roms.

3) Unreal Soccer

A soccer game.

4) Plasma Demo

This is a port of an RGB C plasma demo

5) An Arkanoid clone

A clone of the game Arakanoid.

Recently, digg.com added a new feature called the “DiggBar”.

It frames your page and auto-generates a short url for your content. The issue many people have with this is that the user never leaves the Digg website, which is bad for SEO. This is because:

• Users will most likely link to the shortened Digg URL, and not your site
• Even when a user clicks on your links, it still seems like it is part of digg, not a separate, external link.
• Eventually, they could place advertising on this toolbar, competing against any ads on your page

Recently, because of many criticisms, Digg has changed the behavior of the bar (taken from the Digg blog):

1. New treatment to the behavior of Digg short URLs. All anonymous users, on or off Digg will be taken directly to the publishers content via a permanent redirect (301), no toolbar, straight to the site. Logged in users that have not opted out will continue to see the DiggBar (200). These changes ensure that content providers receive full search engine ‘juice’ or credit for all links on and off Digg. They also ensure that Digg short URLs won’t appear in the indexes of any major search engines.

2. Because we want to ensure the best user experience, the DiggBar will soon only be shown to you when you are logged into Digg. While the vast majority of Digg users find the DiggBar valuable (only a very small number of users have disabled the feature or hit close with any frequency) we understand that many folks were confused when opting out. We want you to be able to have the option to permanently disable the DiggBar with ease. For registered Digg users receiving the bar, we are also making a few changes to make the process more obvious.

However, people can still get to your content through their service if they are logged into their account when viewing.

The following code will remove the DiggBar (and auto-redirect to your actual content) the user to the actual link. To use, place in the header of your website. It will also prevent other sites from displaying your content in an iframe.

Sessions in PHP are pretty easy to use. Here is a simple example on how to start a session:

What is this actually doing?

PHP is an easy language to use and many details are hidden from the programmer. When you store variables in a session, a cookie is dropped on the user’s system (you don’t need to use cookies, but the details are the same) with a unique identifier (this is highly randomized and difficult to reproduce). All of the actual data is stored on your server in a file (which is the default) or a specific database table. The random/unique identifier stored in the user’s cookie is then used as a key to their data.

Insecurities

There are a couple of different ways someone could possibly get access to a session. They are:

• Guessing the session identifier
• Session hijacking
• Session sniffing
• Session storage

Guessing the session identifier: PHP’s built-in session id generator is very random and it is unlikely that someone would be able to guess it.

Session Hijacking:
A valid session id is all that is needed to successfully hijack a session. In order to improve this, we need to see if there is anything extra in an HTTP request that we can use for extra identification. At first glance, and IP address sounds like a good piece of information to use to identifier a user. However, since http is a stateless protocol, you may have users that have a different IP address with every request (I’m not sure how common this is these days, but I used to see this with visitors that were using AOL networks).

A better idea is to use something like the userAgent.

Session Sniffing: Cookies and all other information between a client and server are sent in clear text (meaning someone between a client and the server could grab info such as a session id). So, if are running a site that involves sensitive information, it’s always a good idea to use SSL.

Session storage: If you are on a shared web-server, anyone on the system could potentially access the data stored in your sessions (PHP by default stores all session data in files..usually in the /tmp directory).

An alternative to storing them on the filesystem is to store them in a database (I have written a simple class that does just this. You can download it here.

Also, if you are going to store sensitive data in your sessions, you might want to use a 2-way encryption library such as RC4 (available here)

Here is an easy way to communicate different domains using frames:

Step 1: Create a file called iframe_remote.htm with the following:

The above code contains the data that you want to return to your calling script. I used a simple example with static data. Instead, a PHP (or any other programming language) script could be used to dynamically return data depending on the parameters (this data could also be JSON or XML).

Step 2: create a file called iframe.htm with the following:

Set the iframe src to the full path of iframe_remote.htm. This file should also be placed on the domain that is retrieving the remote data. You should also create a file on the same server as iframe.htm called iframe_dummy.htm.

This technique currently works in all major browsers.

How it works

Under normal circumstances, you can’t access remote data or properties in a frame across different domains due to security measures in place by your browser. The iframe name is the key to retrieving cross-domain data. The above code first loads an iframe with javascript that sets the iframe’s window.name property. After this, the iframe src is dynamically changed to a local file, the windows.name property is not changed, and your browser sees this as a file on the same domain.

Many people have “contact us” forms on their website (or some other kind of form that sends email out using PHP).

A solution to send out the form by email might be the following:

The problem with the above code is that it allows spammers to inject headers into the email, giving them the ability to send email anyone.

It can be done through the From field:

spam@email.com%0Acc:spam2@email.com

Your script will see the %0A as a newline and the headers will be sent like this:

The fix

A way to fix this potential issue is to validate the from address with a regular expression: