Tuesday, October 7th, 2008

IE 8 beta 2 Ajax features

Category: Browsers, IE

<p>Sunava Dutta has detailed the enhancements made to IE 8 beta 2 for Ajax developers including XDR, XDM/postMessage, DOM Storage, offline detection, and more. A lot of great stuff!

XDomainRequest (XDR)

This is an object built from the ground up to make client-side cross-domain calls secure and easy. To reduce the chances of inadvertent cross domain access, this object requires an explicit acknowledgement for allowing cross domain calls from the client script and the server. Additionally, it reduces the need for sites having to resort to the dangerous practice of merge scripting from third parties directly into the mashup page. This practice is dangerous because it provides third parties full access to the DOM. All this comes with the added benefit of improved client-side performance and lower server maintenance costs thanks to the absence of a need for server farms for proxying.

During the Beta 1 timeframe there were many security based concerns raised for cross domain access of third party data using cross site XMLHttpRequest and the Access Control framework. Since Beta 1, we had the chance to work with other browsers and attendees at a W3C face-to-face meeting to improve the server-side experience and security of the W3C’s Access Control framework. As a result, we’ve updated XDR to be explicitly compliant with syntax and directives in the sections of Access Control for requesting simple public third-party data anonymously on the client! (Section 5.1.3 in the Access Control Process Model)

The updates to XDR from Beta 1 allow IE8 to request data from the domain’s server by sending an Origin header with the serialized value of the origin of the requestor. IE8 Beta 2 will only return the response if the server responds with Access-Control-Allow-Origin: *, instead of allowing the XDomainRequestAllowed: 1 header as we did in Beta 1. Other changes include support for relative paths in the open method, and restricting access to only HTTP and HTTPS destinations.

Cross-document Messaging (XDM)

Cross-document messaging is another powerful cross-domain feature that I’ve blogged about in the past. Rather than make a backend request to a remote Web service, this allows sites hosting third-party IFrame-based “gadgets” or components to communicate directly with the parent, without unsafely violating the same site origin policy. This has advantages including improved performance and reliability, as developers don’t have to resort to workarounds that behave differently between browsers and have unwanted side-effects. This technique also removes the need for embedding third-party script in your page, lessening the chance of potential information disclosure vulnerabilities like the disclosure of your sensitive data (such as information in your social network profile) to third parties without your consent.

Beta 2 updates here include moving the onmessage handler from the document object to the window object to better align with the updated HTML 5.0 draft.

window.attachEvent(“onmessage”, HandleMessage);

We also replaced e.URI with e.origin, which is serialized form of “scheme” + “host” + “non-default port”. This is far safer as the URI can carry potentially sensitive information from the origin site that is not needed by the recipient for the decision to grant or not grant access.

if (e.origin == ‘http://www.contoso.com’) 
       
               // process message text     
        }

Finally, the HTML 5.0 draft also mandates that the targetOrigin parameter for the postMessage method now be made a required parameter, as opposed to an optional one. This will make it difficult for developers to make errors by requiring an explicit acknowledgement of the target destination of the message by specifying the origin <URL> or wildcard <*>.

 frameOther.postMessage(“This is a message”, “http://example.com”);

DOM Storage

Today, web pages use the document.cookie property to store data on the local machine. Cookies are limited in capability by the fact that sites can only store 50 key/value pairs per domain. Furthermore, the cookie programming model is cumbersome and requires parsing the entire cookie string for data. While cookies are useful for marking transitions and changes on the client to the server as they are sent with the request headers in chunks of up to 4KB, IE8 brings better alternatives for scenarios involving persisting data on the client and distinctly maintaining sessions in different tabs. The W3C’s HTML 5 DOM Storage objects provide a much simpler global and session storage model for key/value pair string data. Sites can store data for the life of a tab or until the site or user clears the data.

Updates for Beta 2 include changing the name of the persistent globalStorage attribute to localStorage and the removal of the need to specify the domain when writing to the localStorage

// Store a key-value pair.
localStorage.setItem(“FirstName”,”Sunava”);

Finally, we also included improved support of the updated onstorage HTML 5.0 event returned when the storage is changed. We now return the URI when the local storage is changed, so that handlers for pages can know who carried out the latest transaction in the storage space in addition to providing the source to the window of the origin. Furthering the good news, the HTML 5.0 Working Group has incorporated the clear method, which we shipped in Beta 1, into the draft. This essentially allows for script to clear all items accessible in its storage space without having to iterate though the keys.

Connectivity Event

The navigator.onLine property and online/offline events now work on Windows XP as well as Windows Vista. The work to enable this was not trivial, as connection awareness in Windows XP is not quite as advanced as Windows Vista. That said, this will be extremely beneficial for developers, who we believe shouldn’t have to worry about OS differences. The value of connectivity events is particularly appealing when used in conjunction with the localstorage, where data can be cached in case of network loss!

XMLHttpRequest

Introducing the XDomainRequest object in IE8 hasn’t diverted our attentions from constantly tweaking and improving XMLHttpRequest, which will continue to be our flagship object for same-domain communications. Post-Beta 1 energies here have focused on a few bug fixes around reliability and working with the Web Apps Working Group to clarify and improve the draft specification, our compliance with it, and W3C public test cases. A timeout method introduced here in Beta 1 for the convenience of developers is currently being evaluated for adoption in the XMLHttpRequest spec.

// Sets timeout after open to two seconds.
xhr.timeout             = 2000;

ToStaticHTML, to JSON, and fromJSON

What do you do with the strings returned from third parties using XDomainRequest or Cross-document Messaging? In today’s world of increasing script injection and Cross-site Scripting (XSS) attacks, having the option of passing these through a safe parser comes as a welcome relief. As detailed in Eric Lawrence’s post on Comprehensive Protection for IE8 Security, toStaticHTML provides a powerful way of sanitizing your strings by purging potentially executable content.

//Calling:
window.toStaticHTML(“This is some <b>HTML</b> with embedded script following… <script>alert(‘bang!’);</script>!”);

//will return:
This is some <b>HTML</b> with embedded script following… !

In addition, IE8 Beta 2’s toJSON and fromJSON methods provide improved performance as opposed to non-native Javascript deserializers and serializers. Our implementation is based on the ECMAScript 3.1 proposal for native JSON-handling which uses Douglas Crockford’s json2.js API. In addition to the performance benefits of going native, the JSON parser provides a safe alternative to the eval() method, which has been a common and dangerous way to revive JSON objects, and could allow arbitrary script functions to execute.

Related Content:

Posted by Dion Almaer at 7:53 am
6 Comments

+++--
3.2 rating from 54 votes

6 Comments »

Comments feed TrackBack URI

correct me if im wrong, but isn’t this being implemented in almost the exact same way in HTML5?

i understand the benefit if it means you’ll be able to eliminate the use of iFrames entirely, but what good is that to developers if it’s IE only? we’re just going to have to build the iFrame in anyways to be cross-browser compatible…

Comment by JonnyBlazed — October 7, 2008

May be it’s a bit late for last changes to the HTML5 specs, but why the hell ist it storage.setItem and storage.getItem.

According to http://www.whatwg.org/specs/web-apps/current-work/#storage-0 a storage interface has only a few methods, setItem, getItem, clear, key(n), removeItem() and length().

I would keep it simple rename .setItem in .set, .getItem in .get() and removeItem() in remove().

sessionStore.set(‘foo’, ‘bar’); looks for me more usable, like sessionStore.setItem(‘foo’, ‘bar’); with the setItem() method I think there are more types of setX methods available. Maybe setObject, setArray, setReference and so forth, but I *think* you can store everything with just setItem() by now.

Comment by Aimos — October 7, 2008

Storage.prototype.get = Storage.prototype.getItem;
Storage.prototype.set = Storage.prototype.setItem;

Is that so hard?

Comment by eyelidlessness — October 7, 2008

@eyelidlessness:
Getting MS to implement any change is harder than scoring with Paris. And not only that, you’ll also have to convince Mozilla, Opera and Apple to implement that too or else it would be useless. Alternatively you could convince the Ajax libraries to implement that, which would probably be easier, but doesn’t really achieve the purpose of absolute universal adoption. Or in the very least you could ask end-developers to implement that, which kind of defeats the purpose of helping others, when in reality you are only asking them to help themselves.

Comment by Jordan — October 8, 2008

How come that they add HTML 5 features but completely ignore the DOM Level 2 Events Specification that is a recommendation since 2000?

http://www.w3.org/TR/DOM-Level-2-Events/

Sad that we still have to deal with the crappy attachEvent.

Comment by Jeria — October 8, 2008

Refer to the DOM level 3 events.

Comment by TNO — October 10, 2008

Leave a comment

You must be logged in to post a comment.