A very cool approach to validation that plugs right into the YUI library.

I’m using this to provide validation to the DataForm Widget, which is a stepping stone toward the FLEV Widget.

Meanwhile, on the Java front:

• The ASF’s Open Letter to Sun regarding the Harmony Java Compatibility Kit

Last month, Fortify Software posted a white paper describing a security exploit dubbed JavaScript Hijacking. Being a slow news month, a number of online journals trotted out “the end is near” headlines.

Of course, Ajax development groups have been quick to post responses to the “advisory”. Despite the hyperbole, engines like Dojo, GWT, and YUI are not “vulnerable”. Certain applications using Ajax engines may fit a “vulnerability profile”, and if so, there are simple and concrete steps that developers can take.

If your Ajax application exposes sensitive data via raw JSON, do this:

• Enclose JSON responses in JavaScript comment characters, and
• Strip the comments before parsing the response
  Click. Done.

Like many security issues, the “vulnerability” is mainly a developer education issue.

The Dojo Toolkit is providing patches in version 0.4.3 “to inform developers of the potential risks their server-side components may be exposing them to and making it even easier to do the right thing on the client side”.

The Yahoo! User Interface (YUI) Library is now adding a specific header to each request. The server side code looks for the header and refuses to service the request if the header is absent or not valid.

For more about security Ajax applications, see

• A Note on “JavaScript Hijacking“ (Dojo)
• YUI Security“ and Yahoo! Developer Network - Security Best Practices
• Security for GWT Applications
  Since many developers were not aware of this exploit, it is a Good Thing that a White Hat brought it to our attention before the Black Hats did. Though, I hope the next White Hat takes the high road and alerts the development group first. That way, we can have a response out the day the alert is posted, rather than a week or two later.

But, of course, if you happen to be a security consultant, a blindside brouhaha is not bad for business!

This week’s stop on the Tour de Blog is WordPress.com, a free blogging service that also offers “completely” optional paid upgrades.

Setting up a blog on WordPress was easily enough, but there doesn’t seem to be a way to edit the theme directly. There is a CSS editor, and an impressive set of Sidebar Widgets, but no obvious capability for rolling your own. There is a Custom CSS upgrade, but that’s style code only no HTML or JavaScript.

WordPress offers a rich editor and maintains the code in HTML. My initial first impressive is “pretty and featurefull, but sluggish”.

At the end of the series, I’ll provide a roundup with more indepth remarks, but I’d like to give several systems a try before comment on more than the initial impression.

To access the blog system of the week, follow the http://husted.com/ted/blog/index.html link. Feel free to re-up for the feed, so as to give each system a fair test. Of course, if anyone has a preference or other feedback, feel free to comment.

When individuals or communities propose a project to the ASF incubator, it’s not uncommon to see reasons like “recognition” and “exposure to a wider community”.

While these are common reasons, they are not particularly good reasons.

Sure, the software created by many ASF projects is widely used. But, just as many, or more, are relatively unknown. ASF membership is not a ticket to ride. You still have to do the work.

The best reason for joining the ASF is because the development community supports the foundation’s mission.

Once upon a time, the NCSA web server lost its only developer. NCSA was slow to replace the developer, and the project stagnated. Many of the people using the web server needed to make changes in
order to improve stability and scalability. People were posting and discussing patches on the mailing list, but there was no one available to make changes.

Finally, some of the mailing list subscribers banded together, setup their own version of the code, and started to apply their own patches. Not wanting to repeat history, the group organized itself in away that would avoid dependencies on a single developer or a single company.

Over time, the group evolved the notion of the Apache Way, which we now like to call ASF culture. We strongly believe that a codebase belongs to the individuals who create and maintain it, and that a codebase should be a collaboration between individuals. When we put these two ideas together, we come up with the term “meritocracy”, to describe an organization that is run by the people who do the actual work.

The ASF culture contrasts the model of the benign dictator described in Raymond’s The Cathedral and Bazaar. It is also very different that the Linux hierarchy. It’s a model that says any number of people can participate in a project, so long as everyone involved is prepared to work well with others … especially when we disagree.

In a word, our mission is collaboration.

In practice, we fulfill that mission by fostering software development communities. Everything that goes into that, the Apache License, the legal shield, the distribution policies, all speak to the fundamental mission of enabling collaboration.

As to ASF rules, after six years, I’ve been able to identify eleven.

It’s true that working with others is often more work than going it alone. When the kids were young, my wife I would joke that the household chores take longer when the children help. But, nowadays, lo and behold, sometimes, the teens even do their own laundry!

It’s hard. But, it’s entirely worth it.

This site is being used a part of my April “Tour de Blog“.

Visit JRoller for the complete Macaroni archive.