We’re pleased to announce the first Dojo 1.6 beta.

When Dojo 1.6 final is released in February, it will be our first release that includes a number of retrofitted, backwards-compatible, significant changes towards Dojo 2.0.

Because there are a number of changes in progress, we will also soon release Dojo 1.5.1 which includes just the most important fixes for what has been our most stable and popular release ever.

Please check out the in draft Dojo 1.6 beta release notes and the list of resolved issues for more details. Try it out, and as usual file tickets in http://bugs.dojotoolkit.org/. And if you’re interested in Dojo Mobile, many significant additions and improvements have landed in trunk, with many more planned for 1.7 and 2.0.

Stay tuned in February for the Dojo 1.6 release.

We’re looking to create a new collection of case studies about you. If you’re interested in participating, please tell us about your project through the following questionnaire.

We’ve fixed some small nits with the new API documentation tools:

• Old links from api.dojotoolkit.org (including field-level links) should now redirect and point you to the field in question.  An example: http://api.dojotoolkit.org/jsdoc/HEAD/dojox.charting.Chart2D.render
• Links from the static HTML version previously deployed to dojotoolkit.org should now work.  An example: http://dojotoolkit.org/api/1.5/dojo.html#byId
• You can now hit a field (if it exists) directly by appending a hash to the end of the URL.  An example: http://dojotoolkit.org/api/1.5/dojo#byId

The last example will be the final structure of any URL for deep-linking into the new documentation tools.

We hope these and continuing improvements to the documentation are useful to the community at large, and don’t forget: you can download and use these documentation tools for your own custom projects!

Over the past several months we here at Dojo have been contemplating how much of what we do is duplicated effort. When we started this whole project years ago it was because we wanted to do things our own way, but as Dojo and JavaScript in general have progressed, we find ourselves facing the tedium of all the low lying code that has to be written to get Browsers to play nice, not to mention the richer things like our build system and other utilities like dojo.fx, dojo.ready, etc. etc.

At FOSDEM we ended up hanging out with the MooTools crew. We like them; they are always doing interesting things and their framework is one that we’ve always looked at and said to ourselves, "If we ever needed feature X we’d probably just ask for a CLA and patch from them." Anyway, at FOSDEM a group of their developers and ours got together and started brainstorming about closer ways to work together. Since then the discussion has gotten closer and closer to where we are now.

Dojools

Starting today the Dojo and MooTools projects will begin merging and joining forces. Part of this is to share resources – more hands coding makes more code, right? But part of it is, well, we’ll be frank, we’re kind of tired of reinventing the wheel. We love the solutions in Dojo, but at the end of the day, the API is all that matters. It doesn’t matter how you detect that the DOM is ready, so long as when it is your code runs. The same could be said for selector engines, XMLHttpRequest, and a whole host of other things. What this means in practical terms is that we just don’t have to do as much work and, to be frank, after 6 years of working on Dojo, we’re happy to cede some of the more tedious tasks to MooTools. Sure, their architecture isn’t quite the same (or maybe even as good) as ours, but it works. This will free our development team’s time to work on their own projects and maybe start getting paid for it, which brings us to the second point.

Making Dojools Profitable

For the past six years we’ve been writing code and releasing it for free. In our talks with the MooTools team we all agreed that all this free time donated to anyone who happened to want our work just wasn’t quite worth the hassle. Don’t get us wrong, writing the code is fun, but it’s all the other stuff. The bug reports, the hand-holding in the mailing list and on IRC, the constant demand to "compete" with other toolkits (whatever that means). It just sucks the pleasure right out of it. We find ourselves burning nights and weekends to write code for strangers to use and it gets old.

Going forward, the code base will continue to be free, but access to the documentation will require a small "donation" (we’ll probably set a really small minimum, like, say $.25) – frankly, the documentation has gotten too good to be free (we contemplated printing it and just selling it as a book, but micropayments is much more "Web 2.0"). Filing bugs will still be free of course. But we’re working on a system that lets our users put money towards the bugs they care about the most. The bug with the most money donated gets our time and gets in the next release. We think this will cut down on both the number of bugs we get but also help manage expectations. If you have a bug that you think is important, you either need a lot of people to agree with you (which they will if the bug is really broad) or you need to pay a lot (in which case it’s like you’re hiring us as freelancers).

What will we do with the money raised? We’ll probably start sponsoring more meet-ups and sending out t-shirts with the new Dojools logo, but we’ll also be able to compensate the developers who bring you all this great stuff. Certainly no one can argue with that.

Compatibility

As we begin merging functionality we’ll likely retire large portions of both frameworks. MooTools has a great effects library while Dojo has a lot of solid widgets. MooTools ART will likely get shelved in favor of dojo.gfx, dojo.fx will likely be dropped in favor of MooTools’ effects which are really nice, much of MooTools More will either be retired (in favor of existing Dijits) or turned into Dojo widgets themselves, etc.

For backwards compatibility we’ll be implementing the "donation" system as well. For the portions of the MooTools and Dojo cores that are deprecated we’ll allow the users to prioritize which parts we offer compatibility for. Same goes for effects, plugins, etc. We hope this new model will encourage businesses that use our awesome frameworks to recognize the value we bring and to compensate us for our time.

If you have any questions, post them in the comments below. Comments are still free – we haven’t implemented the "donation" system for them yet, either.

If you have Dojo 0.4 through Dojo 1.4 installed on your site, you are strongly encouraged to read all of this message and take immediate action.

We recently had a security review done on the Dojo codebase, and some issues were discovered. Most of the issues were in test files or related PHP files, but there were some issues discovered with a few files used by modules. You are strongly encouraged to remove some files immediately to give yourself the best protection. While we are not aware of any specific exploits, we take security issues very seriously and we encourage you to take quick preventative action.

Quick instructions

Some of the files listed below may not be in your version or build of Dojo. These instructions are listed to be comprehensive across all the Dojo versions.

1. If you use Dojo from the AOL or Google CDN, the issue is already fixed.
2. If you have PHP enabled on your site, turn off PHP for the directories that contain dojo/dijit/dojox. Dojo only used PHP files in some tests and demos, but PHP is not required to use Dojo.
3. Remove the following files:

• util/doh/runner.html – a file used for tests, should not affect production/deployed code.
• dojo/resources/iframe_history.html – in 0.4 it is just iframe_history.html in the dojo directory. This file is used by dojo.back. In Dojo 0.4, it was used by dojo.undo.browser and dojo.io.IframeIO.
• dojox/av/resources/video.swf – used by dojox.av.FLVideo
• dojox/av/resources/audio.swf – used by dojox.av.FLAudio

If you use one of the modules listed above, instead of deleting the files you can do one of the following:

1. Get an updated release with the security fixes.
2. Pull the specific files from one of the updated builds.

If you do your own custom builds, you are encouraged to also get an updated release or pull the correct files, both options listed below.

Updated Releases

New releases of the 0.4, 1.0, 1.1, 1.2, 1.3 and 1.4 branches have been done that contain all the security fixes. These builds only have the security fixes applied, and have some new defaults for some build commands.

Here are the updated builds:

• 1.4.2
• 1.3.3
• 1.2.4
• 1.1.2
• 1.0.3
• 0.4.4

To avoid accidentally copying files test files during custom builds, the build option “copyTests” now defaults to false, and “mini” defaults to true. The “mini” option removes the demos directories and now removes all PHP files regardless of location. With these new defaults, it should reduce the attack surface for the future. If you need the tests or demos in your builds, then pass “copyTests=true mini=false” as part of the build command.

Pull Specific Files

If you have your own custom, modified Dojo source and cannot update to the new builds, you can go to the directories listed in the “Updated Builds” section and grab the files you need from the version that most closely matches your version and just copy them over to your distribution.

Some branches do not have all of these files, just replace the files that exist in your distribution:

Dojo 1.0+

• dojo/resources/iframe_history.html
• dojox/av/FLAudio.js
• dojox/av/FLVideo.js
• dojox/av/resources/audio.swf
• dojox/av/resources/video.swf
• util/buildscripts/jslib/build.js
• util/buildscripts/jslib/buildUtil.js
• util/doh/runner.html

Dojo 0.4:

• iframe_history.html

In addition to grabbing the files listed above, be sure to delete any .php files in the dojo/dijit/dojox directories, if PHP is enabled on your server.

Description of Issues

The main issues that are being fixed in this update:

• Some PHP files did not properly escape input.
• Some files could operate like “open redirects”. An bad actor could form an URL that looks like it came from a trusted site, but the user would be redirected or load content from the bad actor’s site.
• A file exposed a more serious cross-site scripting vulnerability with the possibility of executing code on the domain where the file exists.
• The Dojo build process defaulted to copying over tests and demos, which are normally not needed and just increased the number of files that could be targets of attacks.

Actions to Prevent Further Issues

We take security issues very seriously. We are fortunate that the issues above were brought to us via a security review by community members, and we have addressed the issues as quickly as we can but at the same time making sure we have comprehensive, safe fixes.

We changed the build defaults so that the area with the most issues, tests and demos, are not copied automatically in builds, reducing the surface of attack.

The non-test-related issues were in a very old file that did not get enough attention, or in newer flash modules. We do not expect to have the same issues again for those kinds of files now that we know better how to review them.

However, security requires continued vigilance. To that end we have set up new dojo-sec mailing list to handle any further security-related inquires, see next section.

Summary

Please take immediate action to make sure your site does not contain one of the files listed in the “Quick Actions” section. In most cases the files can just be safely removed, since the modules affected are usually not heavily used. However, there are new builds of all the branches with the security fixes that can be used.

If you have any questions, please feel free to ask our community

If the concern is something you want to keep private, you can contact our newly created security list: dojo-sec at mail dot dojotoolkit dot org.