Ajax Bestiary » Article

Cross Site Scripting – the new old way

Dave Mahon — Tue, 20 Oct 2009 23:02:35 +0000

Cross Site Scripting (XSS) is a big security no-no. It’s never supposed to happen, because as we all know, any script operating within your page has full access to the entire DOM of the page.

Then again, there is so much functionality that we want to implement without reinventing the wheel. Marketing departments want to use third-party tracking tools. The IT folks want to distribute the load for our network heavy site across the third-level domains www.domain.com, static.domain.com and data.domain.com. And users want more functionality than we can hope to provide on our own.

So resigned to the reality that XSS is a legitimate necessity, we need a way to do it. The old way (as far back as the mid-90’s, in fact) was straightforward:



document.write(‘<script language=”JavaScript” type=”text/javascript” src=”http://data.domain.com/myscript.js”>’);

This is of course problematic as it treats DOM nodes improperly and may not even get processed by modern browsers. Instead, jQuery provides access to JSONP which will do the same thing – insert a new script node in the DOM – but do it in an XHTML compliant way.

Accessing JSONP is pretty straightforward:

$.getJSON("http://data.domain.com/myscript&callback=?”, inPageFunction);

The key bit is &callback=? – this causes jQuery to insert a script node into the DOM, which is then immediately executed and returned to the callback function, inPageFunction, like so:



inPageFunction({data:"foo";})

If you forget &callback=? you’ll get the error Access to restricted URI denied. And yes, since we’re inserting a script node, we’re limited to GET requests. And if the call fails, you’ll simply get nothing back – no useful error messages.

Further, the next generation of browsers is coming out with integrated support for cross site XMLHttpRequest, but since when have we not had to code to support multiple versions of browsers?

There are loads of good guides to expand your knowledge:

Implicit Vs. Explicit Conversion in Javascript

Don Albrecht — Mon, 14 Jan 2008 13:13:59 +0000

A question emerged out of my boredom on my flight yesterday. Which is faster, implicit vs explicit conversion. Most javascript developers use implicit conversion out of habit. For example:

!!x; instead of Boolean( x ); and x + “”; instead of String( x);.

I decided to try an experiment for myself and record the performance of casting a number to a Boolean or String on my Windows box in Safari 3, Firefox 2, Opera 9 and IE 7.

The Verdict:

Implicit conversion wins handily, demonstrating over a 7 fold performance increase in one test. Overall, the performance gain for using implicit conversion averaged out to 53% across browsers after 10 tests.

The Numbers:

	Implicit Boolean	Explicit Boolean	Implicit String	Explicit String
Firefox 2	0.162	0.312	0.248	0.358
IE 7	0.042	0.100	0.074	0.152
Opera 9	0.030	0.088	0.020	0.142
Safari 3	0.028	0.036	0.074	0.100
Cross Browser Average	0.066	0.134	0.104	0.188

You can find the code I used after the jump.

The Code:

Taking the Web to the Desktop, Part 2: Mobile Sites

Don Albrecht — Fri, 04 Jan 2008 19:06:13 +0000

I know what you’re thinking, mobile aps run on cellphones and smartphones, not PC’s. Mobile sites are one of the most important and pervasive aspects of this hybrid web ecosystem. Unlike desktops and laptops, mobile sites can assume that the cellular device they are displayed on will have a persistent and portable net connection. Because of this benefit, mobile sites can be viewed as intermediaries to be used with a user may not have access to a traditional internet connection.

Unfortunately, mobile platforms are and always will be limited devices. There simply is no way to put all of the screen real estate of even the smallest monitor into a device that will fit into someones pocket without resorting to origami voodoo. Higher screen resolutions help the situation, but there are limits to the human visual system and 6pt font is almost as eligible on paper as it is on any digital screen.

Other restrictions abound surrounding the mobile platform. From a user interface perspective it’s still a bit of the wild west and mobile browsers have tended to be flaky, inconsistent and underpowered. Safari, Opera and Minimo make significant strides towards eliminating these issues and providing a much richer platform on which to develop. Many cellphones also provide API’s to enable mobile aps to look consistent with, act like and interface with the underlying device.

The inconsistencies across platforms still make mobile devices a difficult nut to crack in terms of development. As browsers, bandwidth and processing power improves, expect developing for them to increasingly less frustrating and in higher demand from users.

Great Article on Ajax Interface Construction & Best Practices

Don Albrecht — Fri, 19 Oct 2007 13:40:01 +0000

IBM Developer Works has released an excellent article on AJAX interface development with a focus on best practices and a recomended work flow.

Check it out here:

http://www.ibm.com/developerworks/web/library/wa-aj-frontend/index.html?ca=drs-tp4207

Standardizing On A Framework

Don Albrecht — Tue, 16 Oct 2007 19:56:06 +0000

Organizational standards are wonderful things. They enforce consistency, help insure institutional competence and can dramatically reduce the learning curve to get additional staff up to speed on a project. At the same time, in the world of AJAX standards can be too slow to adapt to a constantly changing landscape. How do you strike a balance between flexibility and consistency?

Project Specific Framework Selection

This is one of the most common approaches and is definitely the most flexible. Project specific standards basically let the needs of a given project describe the choice of frameworks. A project needing lots of animation and color manipulation may be built using mootools, a complex RIA may be built using dojo & a simpler project may use prototype or jQuery. The problem with this approach is the frequent need to learn new API’s & potential to develop overly superficial knowledge of toolkits that may lead to unnecessarily cumbersome solutions.

Selection of Approved Frameworks

A step beyond project specific framework selection is the adoption of 2 – 4 approved frameworks within an organization. In this arrangement, you try to achieve a balance between project appropriateness and standardization. Usually the frameworks are chosen to accommodate different scales of projects. A natural breakdown is the use of prototype & scriptaculous where scriptaculous may not be used in every project. Another breakdown may combine a simple framework like prototype with a RIA platform like Dojo & an intermediate toolkit like jQuery. In any event, it’s usually a good idea to pick platforms with similar coding styles & api’s to maximize the transference of skills between projects.

Standardizing on a Single Framework

This is definitely a popular approach and prevents any problems with developers needing to relearn things to get up to speed on different projects. Unfortunately, it’s a very high risk approach as toolkits frequently aren’t optimal for every project (e.g. dojo for a brochureware site and prototype for a webmail client). There’s also the unfortunate possibility of a framework transitioning to an inappropriate licensing model or being abandoned as well.

Standardized Coding Practices

This is a strategy that can be adopted independent of your framework strategy. basically, since so many of the various frameworks share constructs and they are all based on javascript. Adopting a set of coding standards can dramatically simplify collaborative development. Some of the strategies to consider are:

Standardized Naming Conventions (camelcase, underscore etc.)
Standardized File Names
Standardized Function Names
Comment Formating
Chaining limits

We’ll discus coding standards more in the future, but since I’ve had several recent discussions on adopting a standard for my organization. I thought I’d share some of our thoughts with you.

jQuery $ unleash the power of selectors

Don Albrecht — Fri, 12 Oct 2007 12:05:21 +0000

While jQuery is many powerful things, Selectors are quite possibly its most capable and useful feature. So here’s the jQuery Selector crash course.

The Ground Rules:

Selectors work just like CSS (1-3) selectors # for ID’s, . for classes p, div, ul, li etc.
XPath an also be used.
CSS & XPATH selectors can be combined

The $ wrapper.

Selectors + $ = jQuery Nirvana. The $() function accepts any selector and returns an object that can be manipulated.
Filters

jQuery filters enhance jQuery Selectors by providing additional logic. Here’s a list of supported filters:

Not (selector)
first
last
even
odd
eq( index) matches an elements index in returned array
gt( index) matches all elements after given index in an array
lt( index ) matches all elements before given index in an array
header matches all h elements (h1 h2 h3 etc)
animated (matches all elements that are currently being animated)
contains( text) matches all elements which contain given text
empty matches all empty elements
has(selector) matches all elements containing an element that matches the given selector
parent matches all elements that are parents / have child element. (opposite of empty)
hidden matches all elements of type hidden
visible (opposite of hidden)

Roll Your Own JS Framework: Is It Necessary?

Don Albrecht — Mon, 08 Oct 2007 15:47:04 +0000

Dustin Diaz recently posted about Rolling out your own javascript interface in his blog.

http://www.dustindiaz.com/roll-out-your-own-interface/

While his code is nice and clean and it does provide what he was hoping to achieve:

There are times when using a JavaScript library is called for. Building large web applications that use a wide array of utility functions that help aid in developing multi-tiered class systems, advanced UI components, complex event models, and heavy use of DOM scripting helpers. Yep. Those are all great.
However, there are other times when you don’t need all that. And often what we end up doing is just importing a few of our favorite functions as globals, and work off those. But what ends up happening in this case is that we lose the particular style that these libraries offer.

In essence, he’s offering a light weight solution to the fundamental issue persistent to all javascript development: (“javascript sucks”). His solution is to coble together a light weight version of prototype containing only what he needs.

My questions are three fold:

Is rolling your own framework worth it? The new generation of code profilers for the various toolkits can dramatically decrease download size and focus on the functionality needed.
Is there sufficient demand for a new ultra light weight toolkit to address these issues?
Why not use full toolkits: Many of them are small enough in compressed form not to make a noticeable difference in load times.

Javascript Menus: The Good, The Bad & The Superfluous

Don Albrecht — Mon, 08 Oct 2007 14:32:27 +0000

Menu widgets: Every toolkit’s got one or more and they sure are easy to use & impressive so the temptation is there to just slap them everywhere. After all, you’re already pushing the toolkit to the client anyway, why not make the most of it.

Before you do, tho I encourage you to consider the following & ask yourself if the javascript solution is really appropriate.

The Good: Reasons to use Javascript Menus

Event Handling.

The biggest reason to use a frameworks menu system is event handling, plain and simple. If you have built an ajax ap that utilizes centralized event brokering. A dynamic menu is all but a necessity for maintainable code & consistent user experience. That said, if the menu doesn’t need to be integrated with the scripts on the page (e.g. A site wide navbar), a dynamic menu is likely superfluous.

Branding.

Lets face it, those slick menus with animated effects are damn sexy. Used effectively, they can really help you capture an audience & encourage a greater depth of exploration by visitors in even the simplest of brochureware sites. Even better, since the menus can be built from
elements they provide excellent accessibility.

The Bad: Reasons to Avoid Javascript Menus

Reduced Accessibility

JAWS especially doesn’t deal well with DOM elements created on the client side. While there are many improvements in accessibility that can come from javascript frameworks (improved tab order, shortcut keys, etc). Those all require an investment in time and energy at setup. These allowances, however, do not fully address the issue of users on reduced capability devices or reliably interface with legacy accessibility tools.

Rendering Overhead

Any dynamically generated menu will add to the initial rendering time of the page. While this may not be an issue on a modern machine running the latest release of an A level browser. Performance hits can be quite dramatic on a machine loaded down with spyware, vintage hardware or other sub-optimal deployment environments.

Visual Noise.

This goes without saying, KISS is one of the primary rules of interface design. A big fancy menu will likely call attention to itself at the expense of other content. After all, what’s going to bring more value to the site and project a slick menu, or quality, fast loading content.

Page Complexity

KISS applies to markup too. It’s a simple fact that the more complex the code, the more opportunities for bugs to slow down the development process. More significantly, the more complex the code, the longer it takes to grok it again when it comes time to make revisions.

I realize that many of these widgets require little or no markup, so the complexity issue can be a mute point in terms of markup. The big risk is of course that the code you use will be deprecated or outright removed from the next release of the framework.

The Superfluous:

This article was inspired by a recent discussion with a fellow developer. He spent 2 days struggling to integrate a pretty slick fish eye menu into the navbar of a website. While the comp’s of the bar looked great & everything was functioning well. The finished site seemed to lack something. It turns out that so many concessions had been made in the design to accommodate the menu’s space & bandwidth requirements. That the entire rest of the project was lackluster for better or worse. Don’t let this happen to you.

Remember, menu’s are not the value added prospect of any site. They are there to make it easy for our users to find the content & navigate.