Strategic Developer | Martin Heller | TAG: AJAX

MORE ENTRIES

TAG: AJAX

May 06, 2008 | Comments: (0)

Backbase, "The Ajax Company," announced today that it officially supports Adobe AIR in its development environment. This was implicit in last month's announcement of Version 4.2, but now it's explicit.

Here's the full release:

Backbase Enterprise Ajax Now Supports Adobe AIR

Allows deployment of Ajax based Web applications on the desktop

SAN MATEO, Calif., May 6^th, 2008. Today, Backbase, The Ajax Company™, adds official support for Adobe® AIR™, a new runtime environment from Adobe Systems for deploying rich Internet applications (RIAs). This integration lets applications built on Backbase Enterprise Ajax run as applications on the desktop across various operating systems.

Applications created with Backbase Enterprise Ajax and deployed on Adobe AIR can access desktop file systems, clipboards, drag and drop events, and system tray/notifications. They can store information locally and operate offline. The combination of Backbase Enterprise Ajax and Adobe AIR opens up new opportunities for web application developers to extend their Ajax solutions to the desktop.

Developers will also benefit from the new integration because they can now use a single platform — Backbase Enterprise Ajax — to build both online and desktop applications. “Now developers can use both their Ajax skills and Web technologies like HTML and Ajax to develop desktop applications,” says Michel Gerin, Backbase VP of Marketing.

Backbase Enterprise Ajax delivers an end-to-end solution for designing, developing and deploying business critical Ajax based RIAs. With an intuitive interface, easy-to-use Ajax tags, and an extensive library of widgets, Backbase increases developer productivity, reduces lead-time for Ajax projects, and leverages existing IT investments.

Applications built and deployed with Backbase Enterprise Ajax and Adobe AIR deliver the best of both worlds. Backbase Enterprise Ajax delivers the features of browser-based RIAs plus speed of development and ease of use. Adobe AIR adds desktop functionality like reading and writing local files, integrating with other applications on an end-user’s computer, and maintaining local data storage on the desktop.

“Applications on Adobe AIR combine the power of local resources with the reach of the Web,” said Robert Christensen, Adobe AIR senior product manager at Adobe. “The union of Backbase Enterprise Ajax with Adobe AIR empowers Ajax developers to use their existing skills and code to build responsive, highly engaging applications on the desktop.”

“The benefits are great” says Gerin. “Enterprise developers and ISVs can boost productivity, extend their market reach, enhance customer satisfaction, improve customer retention, lower costs, and increase profits.”

Best practices and a sample application using Enterprise Ajax with Adobe Air are available on the Backbase Developer Network at: http://www.backbase.com/adobe-air

About Backbase

Backbase, Inc, The Ajax Company^TM, is the leading provider of enterprise software for creating Ajax-based Rich Internet Applications (RIAs). Medium to large enterprises and independent software vendors use Backbase to enhance the usability of their Web applications, migrate fat client applications to the Web, deliver next-generation online self-service applications, and create enterprise mashups. Founded in 2003, Backbase is headquartered in San Mateo, California, USA. Additional information is available at www.backbase.com .

Posted by Martin Heller on May 6, 2008 08:56 AM

April 30, 2008 | Comments: (0)

Ajax Web suite boosts customer interactions

Last week at the Web 2.0 Expo, Ajax framework vendor Backbase introduced a new application suite called Customer Engagement 2.0. As far as I can tell, the 2.0 in the name has nothing to do with the version, as this is all new; it has everything to do with the suite being about Web 2.0, meaning Ajax and Web-based interactivity. The applications are built on top of Backbase Enterprise Ajax.

According to the company, Backbase’s Customer Engagement 2.0

"delivers a comprehensive Suite of Rich Applications that brings customer facing web applications to the next level. Customer Engagement 2.0 helps companies create, manage, and deliver online applications more effectively, so they can truly interact and connect with their customers. Customer Engagement 2.0 is about building a strong connection that drives purchase decisions and stimulates active participation. Engaged customers are one of the biggest assets a company or organization can have in today's competitive marketplace."

The suite has four components: a dashboard or portal presentation tier for mashup applications, including existing widgets and widgets built with the Backbase Enterprise Ajax framework; a forms presentation tier for user-friendly Web applications requiring data capture; a co-browse application; and a chat application.

The suite is still in beta, and the products will also be available separately. There is additional information on the company Web site, and the company would be happy to offer in-depth demos.

Posted by Martin Heller on April 30, 2008 08:18 AM

April 16, 2008 | Comments: (0)

New Backbase version improves Ajax speed, features

Backbase introduced Enterprise Ajax 4.2 today. According to the company, the new framework version offers developers more technologies, allowing for choices between rich and lightweight Ajax functionality, between CSS and XPath, between JavaScript and tag-based development, between JSON and XML, between native widgets and 3rd party widgets and between online and offline RIAs.

The principal improvements to this version are:

New hierarchical data binding
New Data Services module
Support for lightweight Ajax
New and improved widgets
Performance enhancements

A more complete discussion of the new features can be found in Jep Castelein's blog. The offline RIA feature is basically support for Adobe AIR (see sample at left). One of the more ambitious new widgets is a Rich Text Editor.

Speed improvements have been made in all three phases of Ajax operation: load, build, and runtime. The Enterprise Ajax 4.2 product has also been tested against beta 1 of Internet Explorer 8, Opera 9.5 beta, and nightly builds of Safari 3 and Firefox 3.

A Community License for development and deployment on up to 2 server-CPUs is free; this version can be downloaded today. A commercial license is available to businesses needing more CPUs or professional support and software maintenance. A JSF Edition (optimized for Java Server Faces) will be available next month.

Posted by Martin Heller on April 16, 2008 06:30 AM

January 24, 2008 | Comments: (0)

Visual WebGui: Easier, More Secure Web 2.0 Apps?

The basic goal of Web 2.0 applications is to provide the user experience of a desktop application on the Web. As we all know from using Ajax and RIA applications, it's possible to get fairly close. As developers who have built such applications know, it can be hard to get them right.

Visual WebGui, from Gizmox of Israel, attempts to make developing Web 2.0 applications just like developing Windows Forms applications. It's currently a free, open-source product built on top of ASP.NET on the server, with a DHTML presentation layer on the client. It uses an "empty client" model with a "gateway" channel to the server.

In December, Gizmox CTO Guy Peled posted a teaser blog entry entitled Visual WebGui Will Soon Support Silverlight as its Presentation Layer. Today, Gizmox dropped the other shoe with a press release and an alpha product rollout.

Gizmox is funded by venture capital. How are they going to make money (and a profit for the VCs) with a free open source product? According to the press release:

"Though Visual WebGui browser-based solution is and will remain a free, open-source platform, the company will generate revenue from development partnerships, premium enterprise dedicated controls and components, Silverlight extensions, enhanced scalability, plug-in support, customized development and a market place that will be a third party's (Visual WebGui's community developers) channel for their propriety development and other future added-value products and services," said Mr. Navot Peled, CEO, Visual WebGui. "We will announce the commercial version of Visual WebGui in April 2008."

To download Visual WebGui, you first need to register (free) on the site.

Posted by Martin Heller on January 24, 2008 06:00 AM

December 18, 2007 | Comments: (0)

One Window?

Ephraim wonders about the necessity of having BI applications on your cellphone, and offers an alternative: One window.

"a single mobile environment, a single mobile window, if you will, lower case W please, in which information can be sent to or accessed from.

One window, one view, all critical information goes into that pot."

We already have One Window: it's called a Web browser. We also have ways to overcome the limitations of Web browsers, known collectively as RIAs, in which I include Ajax.

The whole idea struck me as funny, though, and brought to mind the inscription on Isildur's Bane (in The Lord of the Rings):

One Ring to rule them all,
One Ring to find them,
One Ring to bring them all and in the darkness bind them

or, in Elvish:

Posted by Martin Heller on December 18, 2007 09:07 AM

November 30, 2007 | Comments: (0)

Three New Products from the Bindows Folks

Sample Bindows Gauges The Ajax developers at MB Technologies have been busy, and now have posted three new products on their Web site: a Bindows gauges library toolkit, BindowsFaces, and the Bindows 4.0 Beta.

The Bindows gauges library toolkit (of which some sample images are at left) is completely free, and comes with a gauge wizard and a free subset of the Bindows Ajax library. The actual gauges are done with vector graphics and are fast enough to be used for soft real-time displays. Try it out online yourself.

Did I mention that it's free?

The BindowsFaces library, as you might guess from the name, brings Bindows-based Ajax capabilities to Java through JSF. It's for Java Faces programmers who'd prefer not to get their hands dirty with JavaScript or go through a compilation step. According to Ran and Yoram Meriaz, who demonstrated these products for me prior to the launch, BindowsFaces "is better than GWT or Oracle ADF." Obviously, they're biased, but it does look interesting. They say that the technology used to create BindowsFaces could now be used to marry other server technologies to the Bindows client libraries. BindowsFaces is a new component of Bindows 4.0.

The Bindows 4.0 beta "probably makes Bindows the most advanced professional Ajax framework in the market," according to the Meriazes. Again, take that cum grano salis, but the primary design goal of Bindows 4.0 is to add the "ability to define a fully working application without writing a single line of JavaScript." To join the 4.0 beta program, contact sales@bindows.net.

Posted by Martin Heller on November 30, 2007 01:29 PM

June 20, 2007 | Comments: (0)

InfiView Demos

I'm deep into the process of reviewing InfiView, a framework for building interactive and dynamic Web 2.0 maps and diagrams that is implemented on top of Bindows. I'll hold my comments for the review, but I thought you might be interested in the online demos: InfiView™ : Demos / Experience.

The Flight Browser demo (click on the picture at the left) is especially interesting, as it combines a live Google Map with an interactive InfiView annotation layer. Understanding this particular sample from the source code and documentation took some effort, as well as some queries to support, but I think I've got it now.

By the way, don't expect real airline routes from this demo. "The airline routes are drawn using SVG in Firefox and VML in Internet Explorer. Airports are taken from a collection of airport positions. The airline routes are created by randomly connecting pairs of airports."

Posted by Martin Heller on June 20, 2007 06:00 AM

June 06, 2007 | Comments: (0)

Google Gears: Standing the Smart Client on its Head

You may have noticed by now that I'm not the go to guy for breaking news; I'm more the guy who takes it apart and figures out what what it means for developers. Even if I wasn't crazy busy last week when Google Gears was announced, and then away for a long weekend for my college reunion, it still would have taken me awhile to explore it enough to talk about it.

I see Google Gears as a Smart Client stood on its head. What Microsoft calls a Smart Client is basically a desktop Windows application designed for intermittent connectivity to a server. Google Gears is basically a browser application designed for intermittent connectivity to a server. In both cases, you get full functionality when you're connected, and may have reduced functionality when you're disconnected. A Smart Client application is likely to have a richer interface and better performance than a Google Gears application, but it's also likely to require more work to develop the Smart Client.

Google Gears is implemented as a browser add-on for Windows and Macintosh computers. In Internet Explorer, it installs as an ActiveX control, a Browser Helper Object (BHO), and a Browser Extension. In Firefox, it installs as a Firefox extension. It displays a menu item for settings in both browsers.

Gears has three major modules that you can call from JavaScript: LocalServer, Database, and WorkerPool. LocalServer gives you a local cache for resources that you'd otherwise serve from the Internet. Database gives you a local instance of SQLite with a full-text search extension. WorkerPool lets you run JavaScript in a separate worker process so that it doesn't block the UI. A fourth module, the Factory, is used to instantiate all the other Google Gears objects.

Now, if you're the sort of person who thinks that ActiveX controls, Java applets, and other forms of "mobile code" are a security risk, then you should avoid Google Gears as well: it's just another ActiveX control and BHO. There is a certain amount of protection built into the system: for example, Gears does ask for opt-in permission before it lets a site write to your local hard disk. It also implements a same origin policy. But it can't possibly have industrial-strength security, and I suspect that you shouldn't use it for sensitive information without additional defensive layers of security.

The bottom line: Google Gears looks like a reasonable way for a developer to turn a pure Web application into a browser application that can also run disconnected from the Web. It's clearly at a beta level, but in my brief examination it seems to be fairly solid.

Posted by Martin Heller on June 6, 2007 06:00 AM

May 18, 2007 | Comments: (0)

Microsoft Popfly Released

John Montgomery is an old friend who is currently at Microsoft. He has alluded to working on a project codenamed "Tuscany" in his blog, but has been quiet about what it actually is, until this morning.

Welcome to Popfly demonstrates the technology.

The Genesis of Popfly or What I've Been Doing for the Last Year explains what Popfly is and how it came about.

Why I Think Popfly is Cool gives John's top-ten list.

And, the Popfly Alpha is at http://www.popfly.ms/.

The short summary is that Popfly is an easy way to build and share mashups, gadgets, Web pages, and applications. It requires Microsoft SIlverlight 1.0 Beta, which is available to anyone, but Popfly itself is currently in private alpha. I have sent my request to join in through the normal mechanism (by trying to log in at the Popfly home page), but haven't yet gotten access.

I'll let you know more when I have gotten my hands on it.

Posted by Martin Heller on May 18, 2007 11:56 AM

April 27, 2007 | Comments: (0)

Client-Side Web References

Two books live on my desk when I'm working on Web pages with client-side scripting: David Flanagan's JavaScript: The Definitive Guide, 5th Edition (O'Reilly, 2006, 994 pp., $49.99, ISBN 978-0-596-10199-2), and Danny Goodman's Dynamic HTML: The Definitive Reference, 3rd Edition (O'Reilly, 2007, 1307 pp., $59.99, ISBN 978-0-596-52740-2).

They're both huge books, and their content overlaps substantially, but they both keep earning their spots. I reach for Flanagan if the question in my mind is primarily about some aspect of JavaScript, and for Goodman if the question is primarily about some aspect of HTML, XHTML, CSS or the Document Object Model.

Flanagan has two tutorial sections. Part I explains core JavaScript, and Part II explains browser DOM scripting. I read them once: they were nice. I don't think I have looked at them again since the latest edition of the book arrived.

It's the reference sections of the two books that I return to over and over. Flanagan Part III is a complete reference to core JavaScript 1.5 and ECMAScript version 3. Flanagan Part IV is a reference for client-side JavaScript. It's notoriously difficult to write sophisticated cross-browser JavaScript: Flanagan helps you figure out what to do when, for example, an area is outside the DOM Level 2 standard and implemented differently in IE and Firefox.

Goodman Part I is a Dynamic HTML reference, with five subsections: HTML and XHTML, DOM, Events, Style Sheets, and core JavaScript. Part II has cross references to attributes, properties, methods and events. Part III has tables of color names, HTML character entities, keyboard event character values, editable content commands, HTML/XHTML DTD support, and a cross reference to Mozilla-based browser version numbers.

Posted by Martin Heller on April 27, 2007 06:00 AM

March 28, 2007 | Comments: (0)

Three Pitches

Last week, I got three developer-oriented PR pitches for coverage. None of them got me fired up right away, so let me put it to you: do you want to hear more about any of this stuff?

First, there was Backbase. They have been pricing their AJAX framework kits, which my esteemed colleague Peter Wayner reviewed favorably last November, at $6,000 per CPU for the Client Edition, and $8,000 per CPU for the JSF and Struts editions. That's pretty steep unless you're an Enterprise. Now they're offering any edition at $2,000 per developer seat, which includes a runtime license for two CPUs.

Does that whet your interest? Why or why not?

Then, there was salesforce.com. Peter Coffee wrote to let me know what their Spring '07 release includes AppSpace, "a facility for building customer-facing portals using AppExchange applications and other assets built on the Apex platform." Peter says that "this is a real game-changer for quickly creating and deploying a customer-facing Web presence with a scalable On Demand infrastructure."

Are customer-facing portals important to you? If so, would AppSpace make you want to jump on the salesforce.com bandwagon?

Finally, there was IBM Developer Relations, who wanted me to know about developerWorks Exchange, their developer community, and IBM CODESTATION, their 3-D area in the virtual world of Second Life.

I couldn't actually get the CODESTATION link to work, but I was able to find IBM CODESTATION by name and teleport there from within Second Life, once I registered and logged in. IBM says that they are "helping developers form social networks to work together more collaboratively and accelerate the software development process."

Are you looking for a new social network for programming? If so, does either of these IBM initiatives appeal to you?

Let me know how you feel about any of these pitches by leaving a comment here.

Posted by Martin Heller on March 28, 2007 06:00 AM

February 19, 2007 | Comments: (0)

Ajax Design Patterns

The other day I got a press release that started:

Sehr geehrte Redaktion,

Letzte Woche sind einige Neuerungen auf http://www.canoo.net livegeschaltet worden: Vorschläge wie bei Google Suggest...

I got a big kick out of reading the German, but I can't expect you to share that. The English translation was given later in the same release:

Dear editor,
Last week the following changes went live at http://www.canoo.net: AJAX Preview similar to Google Suggest...

I had just been reading Ajax Design Patterns by Michael Mahemoff (O'Reilly, 2006, 635 pp., $44.99, ISBN 0-596-10180-5), and I thought to myself: "Ah, the Suggestion pattern. I wonder how they're doing on throughput, since that pattern typically incurs an XMLHTTPRequest call to the server on every keystroke, unless you throttle the calls." When I tried out the site, I was pleasantly surprised at how quickly the word list popped up.

When I opened the back cover of the book and found the Suggestion pattern listed, I turned to the page reference, and reread the entry. Sure enough, the pattern was based on Google Suggest, as well as Kayak, Delicious, and Amazon. I remembered the throughput problem and the throttling solution correctly, but rereading the pattern entry reminded me of several coding details, alternative solutions, and related patterns.

Since reading the GoF Design Patterns book years ago (note to self: where has that book disappeared to?) I have found it useful to think in terms of design patterns for much of my software development work. It has also been useful to refer to design patterns when discussing solutions with other developers. I have found the various extensions to the design patterns useful as well: C# Design Patterns, J2EE Design Patterns, Enterprise Integration Patterns, and Refactoring to Patterns.

Ajax Design Patterns seems to be the right book at the right time. It covers 60(!) design patterns for Ajax development, classified into four groups: Foundational Technology, Programming, Functionality and Usability, and Development. XMLHTTPRequest Call is a Foundational Technology pattern. Submission Throttling is a programming pattern. Suggestion is a Functionality and Usability pattern. DOM Inspection is a Development pattern.

This is an excellent book. I could quibble about the number of minor typos, and I could wish for an updated edition, especially in the area of Ajax frameworks and libraries. On the other hand, the book is supported by a Wiki, so current content is as close as your Web browser.

Posted by Martin Heller on February 19, 2007 06:00 AM

February 14, 2007 | Comments: (0)

Ajax on Rails

On January 24, I discussed a not-very-focused book on Ajax, and mentioned its diversion to a discussion of Rails:

"Near the end of the journey, we detour to Ruby on Rails, and finally get to its Ajax support; I'm not completely sure why Woychowsky bothered with that particular side trip."

And now for something completely different: a pleasant surprise. Scott Raymond's new book Ajax on Rails (O'Reilly, 2007, 336 pp., $39.99, ISBN 0-596-52744-6) discusses Ajax and Ruby on Rails, focusing on the Ajax support in Ruby on Rails in just about the right depth for most developers, and offering some valuable insight without going too far afield.

Scott is a Rails insider: he's one of the developers of the framework. His book has the unmistakable ring of experience, and it is well-organized and well-written. The chapter on RJS (Ruby-generated JavaScript) is especially welcome, but his chapter on debugging and testing Rails is quite valuable, and his chapters on Rails security and performance will help people lock down and tune up their applications.

I'm not sure how much value the extensive references to the Prototype and script.aculo.us JavaScript libraries will have for Rails developers. Is this just dross to get the page count up, or is it useful? I've done enough JavaScript development that I might come down on the "merest dross" side of the argument, but there may well be Ruby developers for whom JavaScript is enough of a mystery to justify the space spent on this reference material.

Posted by Martin Heller on February 14, 2007 06:00 AM

January 29, 2007 | Comments: (0)

REST and CRUD: the Impedance Mismatch

As you probably know, CRUD is, among other less savory things, the most common acronym for the four basic functions of persistent storage: create, retrieve, update and delete. As we discussed on January 26th, RESTful architectures apply these four basic functions in a regular way to a set of resources. If the RESTful architecture is a Web site, then the CRUD operations create, retrieve, update and delete map to the HTTP methods GET, PUT, POST, and DELETE.

What's wrong with this picture? The HTTP 1.1 standard defines eight methods (or verbs): HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, and CONNECT. Web service clients sometimes use all eight. Web browsers, however, typically only issue GET, HEAD, POST, and sometimes PUT requests. Most browsers are not currently capable of issuing HTTP DELETE requests.

Tilt!

So how does Ruby on Rails 1.2 implement a RESTful interface for the delete action without getting an HTTP DELETE request? Simple: it cheats.

Actually, this gets ugly. To cause a delete action, when implementing the :method => :delete option in link_to, Rails uses JavaScript to generate a dynamic form with a hidden field named _method, and sets the value of the field to delete. When a Rails application receives a form with a _method parameter, it causes the parameter value to override the real HTTP method verb.

I thought I understood the benefits of RESTful architecture, but this implementation leaves something to be desired.

Posted by Martin Heller on January 29, 2007 06:00 AM

January 24, 2007 | Comments: (0)

AJAX, by Edmond Woychowsky

As I mentioned on January 10th, I'm going through a stack of AJAX books. The first of the bunch is AJAX: Creating Web Pages with Asynchronous JavaScript and XML, by Edmond Woychowsky (Prentice-Hall, 2006, $44.99, ISBN 0-13-227267-9).

In general, this is a well-written book, with a lot of useful information to present. On the other hand, it's written with an attitude: some will find it refreshing or amusing, and others will find it annoying. I started off in the former camp, and ended up in the latter.

Woychowsky starts by discussing Web pages and their taxonomy, introduces Ajax concepts, explains HTML, XHTML, and CSS, and offers a brief introduction to JavaScript. You can skip all that if you already know the material. Then he offers a chapter that discusses "Ajax Using HTML and JavaScript", which is something quite primitive that wouldn't normally be called Ajax; he does it from the ground up in 46 pages, and manages to throw in MySQL stored procedures. Don't ask.

Then it's off to a whirlwind tour of XML, and then on to 25 pages on XMLHttpRequest, which is a key component of Ajax as we know it. Then, finally, he's ready to talk about traditional Ajax, using XML and XMLHttpRequest. After that, he wants to talks about Ajax using XSLT, because he's a self-described XSLT geek, so he first has to wander off into XPath and XSLT-land; again, skip a couple of chapters if you already know that stuff. Near the end of the journey, we detour to Ruby on Rails, and finally get to its Ajax support; I'm not completely sure why Woychowsky bothered with that particular side trip.

Woychowsky's book is part of Bruce Perens' Open Source Series, so maybe I should cut Woychowsky some slack about the gratuitous slurs against Microsoft in his book. On the other hand, some of them are inaccurate and misleading: for example, when he discusses ATLAS, which was the temporary codename for what is now called ASP.NET AJAX, he wanders off into a rant about "not invented here" syndrome, and then explains that he can't run ATLAS because he doesn't have $549 for Visual Studio 2005 Professional. Excuse me, Edmond: Visual Web Developer 2005 Express Edition is free for the downloading, and works just fine with ASP.NET AJAX.

Woychowsky presents his own home-grown Ajax library in Chapter 12, "Better Living Through Code Reuse." It's not bad at all: you could do a lot worse. And you could easily modify it to your own devices and desires. (The sample code is here, but you'll understand it better if you have the book.)

This is definitely not a book about using commercial Ajax libraries, or even free Ajax libraries, although Woychowsky likes the free Sarissa library and gives it 5 pages. On the other hand, the book is a good foundation for doing Ajax development yourself, and once you know how to do that you can intelligently examine the construction of the Ajax library your management wants you to evaluate, to see if it actually makes sense for your application.

Posted by Martin Heller on January 24, 2007 06:00 AM

January 10, 2007 | Comments: (0)

AJAX in Print

My so-called office is getting smaller and smaller, because my books no longer fit on the shelves, and I don't really have room for more shelves. I'm making some progress clearing out old stuff, but it's hard because I still use some books from 20 and even 30 years ago. It's actually easier for me to discard old computers and software than old books. This was to my benefit a couple of years ago when I was working on an intellectual property case that hinged on computer technology from the 1980s, but that's another story entirely.

Anyway, the newer books are in piles on the floor; the tallest pile is about 4 feet high. One of the shortest piles contains half a dozen books about AJAX:

AJAX: Creating Web Pages with Asynchronous JavaScript and XML, Edmond Woychowsky, Prentice-Hall, 2006, $44.99, ISBN 0-13-227267-9
Ajax Design Patterns: Creating Web 2.0 Sites with Programming and Usability Patterns, Michael Mahemoff, O'Reilly, 2006, $44.99, ISBN 0-596-10180-5
Ajax Hacks: Tips & Tools for Creating Responsive Web Sites, Bruce W. Perry, O'Reilly, 2006, $29.99, ISBN 0-596-10169-4
Build Your Own Ajax Web Applications, Matthew Eernisse, SitePoint, 2006, $39.95, ISBN 0-9758419-4-7
Pragmatic Ajax: A Web 2.0 Primer, Justin Gehtland, Ben Galbraith, and Dion Almaer, Pragmatic Bookshelf, 2006, $29.95, ISBN 0-9766940-8-5
Understanding AJAX: Using JavaScript to Create Rich Internet Applications, Joshua Eichorn, Prentice-Hall, 2006, $39.99, ISBN 0-13-221635-3

Do you need any or all of these books? I'm not sure. I can only tell you what each book is about, once I've read them myself. Stay tuned.

Posted by Martin Heller on January 10, 2007 06:41 AM

January 08, 2007 | Comments: (0)

Subverting AJAX: Prototype Highjacking

One of the most interesting parts of the JavaScript language is the prototype property, which underpins the language's object-oriented inheritance. In JavaScript, functions are a specialized kind of object; every function (and indeed every JavaScript object) has a prototype property that refers to a predefined prototype object, which comes into play when the function is used as a constructor with the new operator.

Prototypes are not limited to user-defined classes. Even built-in JavaScript classes have prototype properties, and you can assign values to them.

This is extremely powerful. It is also extremely dangerous. Using prototyping, an attacker can hijack standard functions in a way that breaks security without causing any error message. Browsers try to prohibit this by dropping the prototype property for some of their internal functions, but there's a way around that protection.

At the 23rd Chaos Communication Congress, held at the end of December in Berlin, Stefano Di Paola and Giorgio Fedon gave a talk called Subverting AJAX (PDF), in which they explained exactly how to do this. Coupled with a cross-site scripting attack and a cleverly crafted phishing email, such an attack could turn an AJAX application into a keylogger with a man-in-the-middle attack strategy. Consider the following diagram, from Di Paola and Fedon's paper:

What's happening here is that the attacker has hijacked the browser's XMLHttpRequest object, and wrapped it with his own keylogging logic. How hard is this to do? Not very hard at all. The key code would be:

var xmlreqc=XMLHttpRequest;
XMLHttpRequest = function() {
    this.xml = new xmlreqc();
    return this;
}

This is fairly subtle, but it's devastating. XMLHttpRequest has been redefined to be a wrapper for itself. Any time a new instance of XMLHttpRequest is intended to be created in subsequent code, the wrapper method will be created instead. It now doesn't matter that the original XMLHttpRequest function didn't have a prototype property: the new one does.

Once the attacker has prototypes at his disposal, he can redefine key methods. For example, he can redefine the send method to sniff and/or modify the content, as shown in the figure above and the following code:

XMLHttpRequest.prototype.send = function (pay){ // Hijacked .send sniff("Hijacked: "+pay); //log the original message pay=HijackRequest(pay); //change the message return this.xml.send(pay); //send it on }

The classic response to this kind of exploit would be "disable JavaScript in your browser." Unfortunately, AJAX applications inherently require JavaScript, and most people really like the improved user experience of AJAX applications compared to conventional Web applications.

I don't have a good solution, other than constant vigilance on the part of every author and user of AJAX applications. We're back to "Don't talk to strangers," kids. In the words of the original CERT bulletin about cross-site scripting,

"users can gain some protection by being selective about how they initially visit a Web site. Typing addresses directly into the browser (or using securely stored local bookmarks) is likely to be the safest way of connecting to a site."

(Thanks and a tip of the hat to Roy M. Silvernail, who alerted me to this exploit.)

Posted by Martin Heller on January 8, 2007 10:24 AM

January 03, 2007 | Comments: (0)

AJAX 101

In all the discussion of the difficulty of AJAX, the relative merits of the various free and commercial AJAX libraries, the AJAX support in control packages, and the AJAX support built into or added onto Web server technologies like Ruby on Rails and ASP.NET, it's easy to forget that AJAX is essentially a fairly simple idea. When you strip it down, AJAX is a way of using JavaScript, CSS, the browser DOM, and the Microsoft XMLHTTP interface to make asynchronous calls to the server to update selected data.

Here's some sample code in JavaScript, which Microsoft provided years ago to illustrate how to use XMLHTTP:

var xmlHttpReq = new ActiveXObject("MSXML2.XMLHTTP.3.0");
xmlHttpReq.open("GET", "http://localhost/books.xml", false);
xmlHttpReq.send();
WScript.Echo(xmlHttpReq.responseText);

How hard is that?

Yes, yes, I know that the object is now called "Microsoft.XMLHTTP", and that the last line of the sample is code for the Windows Scripting host, and won't run on a Web site. Instead, you would use dynamic HTML to update a region on the page. You'd have a named DIV, and you'd set the DIV's innerHTML element to the new content.

Again, how hard is that?

Now, is there more to it? Of course: I'm oversimplifying, or there wouldn't be any good reason for all those AJAX libraries. The minute you try to make an AJAX application work on multiple browsers and/or multiple operating systems, you run into compatibility issues. You might want to use a different data format than XML. You might want to build additional layers on AJAX to implement special effects, like the ones in Gmail and Flickr that helped the AJAX technology take off. The list of what you might want to do is almost as long as the list of solutions.

But enough about what I think. What do you think?

Posted by Martin Heller on January 3, 2007 06:49 AM

Technology White Papers

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert