Dev411 Blog

People are reporting a Rails 1.1.5 routing vulerability where accessing certain URIs will crash Rails. The problem has been reported on Mongrel, WeBrick and FastCGI. Piers Cawley is working on an explicit routes fix for Typo and discusses the issue on his blog. This has not been mentioned on the RoR blog yet. Good thing for public forums.

It was recently announced that Rails 1.1.0, 1.1.1, 1.1.2, and 1.1.4. have a very serious security hole. Although the RoR blog hasn't discussed exactly what the hole is, it has been rumored to involve uploading of .rb files to execute arbitrary code on the server (UPDATE: now confirmed). Typo only allows file uploads by administrators so certain applications may be somewhat safer. (UPDATE: Running arbitrary code was fixed in 1.1.5 however you could still crash it. 1.1.6 has been released to fix these lingering bugs. Just change 1.1.5 to 1.1.6 below).

It seems that Firefox's basic xml parser gets confused by xmlns and namespacing. Namely that if the feed is defined by:

<feed xmlns="http://www.w3.org/2005/Atom"
xmlns:default="http://www.w3.org/1999/xhtml"
xmlns:dc="http://purl.org/dc/elements/1.1/">

Firefox's basic XML tree renderer won't recognize the XML if the entry content is wrapped by:

    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Show submenus depending on where your users are.</p>
      </div>
    </content>

Basically it confuses xhtml:div with atom:div. If xmlns is removed from the div, Firefox is fine.

People don't generally use Firefox's XML tree to read Atom and the W3C Feed Validator doesn't have a problem with it so I'm wondering if this bug exists anywhere else.

This shows up when using XML::Atom because it uses XML::LibXML, which explicitly adds xmlns everywhere.

UPDATE 1: I thought it would be useful to include the following:

The Atom spec (section 4.1.3.3 Processing Model) says:

UPDATE 2: Apparently this behavior may be by design. Not very useful IMO but perhaps intentional. I think it would be more useful to have some Firefox settings that let you switch to XML tree mode or apply a default stylesheet.

I just set up Planet Catalyst at http://planet.catalystframework.org to aggregate blogs about the Catalyst MVC framework. It is also linked from the main Catalyst homepage and Planet Perl so you can reach it from there. The planet is focused on articles related to Catalyst and friends which means it filters articles on catalyst, dbic, dbix(::|-)?class or html(::|-)?widget, h::w or handel (case insensitive). Let me know if there are any other topics of interest that should be included.

Planet Catalyst is powered by Plagger, a Perl-based RSS/Atom feed aggregator. Thanks to Tatsuhiko Miyagawa for writing Plagger and answering my questions on the #plagger FreeNode IRC channel. It was very easy to add filtering on keywords by specifying a rule in the config file.

If you have questions or would like a blog added, send email to the catalyst-dev mailing list, comment on this article or ask on #catalyst / #catalyst-dev perl.org IRC channels.

I finally got around to upgrading Typo here to the latest trunk. At first I was waiting to upgrade to 4.0.0 (officially r1161) but decided to move to SVN after hearing about some post-r1161 bugfixes and it seems like a fairly common practice to run off SVN, at least for Typo. I've hacked a few changes onto 2.6.0 and had to manually merge the mods to r1181. Merging one's own mods to the trunk was discussed today on the Typo mailing list under the heading "Version Controling Modifications" and most of the respondents have their own mods and use Chia-Liang Kao's SVK to keep their mods synced with the trunk. Scott Laird has a number of articles on using SVK with Typo's repo. Seems like running off of the trunk with SVK may be a best practice for Typo installations.

Hopefully I'll be on SVK for my next upgrade since I had to manually update the following files this time around:

• app/controllers/articles_controller.rb
• app/helpers/application_helper.rb
• app/helpers/articles_helper.rb
• app/views/articles/_article.rhtml
• app/views/articles/_articles_toc.rhtml
• app/views/articles/index.rhtml
• app/views/articles/read.rhtml
• components/plugins/sidebars/category/content.rhtml
• components/plugins/sidebars/xml/content.rhtml
• config/routes.rb
• themes/azure/layouts/default.rhtml

I've moved all my Azure theme changes to a custom theme so the changes are easier to keep track of and don't interfere with the base Azure theme.

I've updated my Installing Typo article to cover SVN checkout, Feedburner customization and rake migrate. The Typo TOC How-to has also been updated for 4.0.0.

While code diving, I was happy to see lots of refactoring though the code is still pretty easy to follow and modify. Hopefully soon I'll be back to hacking more enhancements. I'm particularly interested in extending the sidebar functionality so groups of plugins can be positioned in multiple locations on the page, e.g. a 3-col layout.

Upgrade Gotchas

• UPDATE: this section on Feed URIs seems to be inaccurate because I chose to use my old 2.6.0 routes.rb file. I didn't think the feed URIs would change. New approach: don't assume anything has stayed the same and move to svk.
  Feed URIs: Typo 4.0.0 changes the feed URIs from 2.6.0 so if you have these URIs registered somewhere, e.g. Feedburner or LiveJournal, you'll need to upgrade your URIs. The new URI styles are:
  • http://www.dev411.com/blog/xml/feed/feed.xml?type=feed&format=atom
  • http://www.dev411.com/blog/xml/feed/feed.xml?type=feed&format=rss20
  For comparison, the 2.6.0 style is:
  • http://www.dev411.com/blog/xml/rss/feed.xml
  Everytime this URI changes I need to file a support ticket at LiveJournal whereas on Feedburner I can change the URI myself. I've been wondering if I should just have LiveJournal use the Feedburner URI ;)
• Categories sidebar no longer alphabetized: My categories list was no longer alphabetized so I edited the components/plugins/sidebars/category/content.rhtml page from:

  <% for category in @categories -%>

  to

  <% for category in @categories.sort {|a,b| a.name <=> b.name} -%>

• config no longer used in ArticlesController: If you used config, the code needs to be changed like this example:

  config[:blog_name]

  to

  this_blog.blog_name

If you are hosting at Dreamhost, you are better off letting Dreamhost host the DNS for your domain as well. This is because Dreamhost can change the IP of your server without notifying you. They will update their own DNS servers when this happens but this won't help if you if your DNS is being hosted elsewhere. Use their nameservers and you should be all set.

Sometimes when the DNS is pointing to the incorrect IP, you'll see the following error:

Planet engines are applications that aggregate RSS/Atom feeds and generate composite feeds as well as a website. The generated feeds typically include RSS, Atom, FOAF and OPML. Two popular open source planet engines are Planet and Plagger. I've used both to create planet-style websites and here are my observations:

I just put together an online JavaScript Compressor interface to Dojo Toolkit's JavaScript Compressor, custom_rhino.jar. The JavaScript Compressor is used in the final stage of the Dojo Toolkit build process so gets a lot of use. Although there is already an online version, ShrinkSafe, I put another version together because:

• It would be nice to have a web app that makes custom Dojo builds people don't have to install the JDK and ant to get a custom Dojo build. This is the primary reason and the compressor is a first step in that direction.
• There have been some reports that the JS produced by ShrinkSafe doesn't work (maybe it's using an outdated custom_rhino.jar?). I want an Dojo-based online system to use myself.
• It's nice to have more Dojo, Prototype and Scriptaculous integration tests. I used the client code from ShrinkSafe which uses Dojo to add additional file and do Drag-and-Drop along with the Lucid theme which relies on Prototype and Scriptaculous. I learned that dojo.js 0.3.1 needs to be loaded before scriptaculous.js 1.6.1 or Scriptaculous will break Dojo (I updated the Dojo and Prototype Together article). My minimal use of the Lucid theme actually doesn't need scriptaculous.js so I can get away with loading just dojo.js 0.3.1, prototype.js 1.5.0 rc0, effects.js (part of Scriptaculous 1.6.1) and lucid.js. lucid.js is part of the Lucid theme.

The JavaScript compressor eats its own dogfood and uses prototype.js, effects.js and lucid.js compressed into a single-line, single file. Here are the compression sizes and ratios for the files. Generally you save about 30%.

A number of people are using JavaScriptCompressor.com which is running Dean Edwards' .NET JavaScript compression code. This can be used after Dojo's compressor for even more compression.

Often times you'll want to customize your response specific to the View being used, e.g. setting extra headers. This can be done directly in your View class by creating a process method. All View base classes have a process method defined in Catalyst::View that gets called at rendering time. By adding a process method in your subclass and redispatching to the parent you can do some preliminary processing.

Yahoo! provides a number of cheat sheets for their YUI library widgets however these are in PDF format and not usable as wallpaper. PDF is great as a transport format because you can provide one version for everyone, however transforming it makes it more appealing for actual use. I prefer cheat sheets in standard image formats that can used as wallpaper, espcially useful with virtual desktops.

Here are the YUI 0.11 cheat sheets converted to PNG images of various sizes. Let me know if any other sizes would be useful.