David finally admits that the cat is out of the bag and gives full disclosure on the critical security hole in Ruby on Rails:

With Rails 1.1.0 through 1.1.5 (minus the short-lived 1.1.3), you can trigger the evaluation of Ruby code through the URL because of a bug in the routing code of Rails. This means that you can essentially take down a Rails process by starting something like /script/profiler, as the code will run for a long time and that process will be hung while it happens. Other URLs can even cause data loss.

It’s good that the RoR team has released the details of the problem and are working hard on all security aspects of the framework. They’ve even started a new mailing list for dealing with security issues. That’s a Good Thing.

But still, I’m left wondering why David decided to handle this the way he did. This exercise in security-by-obscurity certainly wouldn’t have prevented a determined person from finding the diff in the code and exploiting it. And yet it made it very difficult for admins with sites running RoR to make informed decisions on how to handle the news.

I just don’t understand, and I’m apparently not the only one…

Quoth Evan Weaver:

Core team discovered a security vulnerability in recently released 1.1.4., and then came to the conclusion, same as I did, that 1.0 and some intermediate 1.1 releases are not affected. They have provided a patch, but no explanations, which is beyond frustrating to those who have to decide whether its better to risk breaking their application by applying this mysterious patch, or continue running with a vulnerability of unknown severity.

Indeed.

The time will come when each of the other frameworks will be found to have critical security flaws as well.

The only question is… how will they handle it when it happens?

Quoth the Ruby on Rails blog:

This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn’t affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.

The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assalients.

Nate took a look at the code and ran a quick diff on it, but he says he looks like they may have renamed a few files. Interesting.

According to the devs, the problem affects 0.13, 0.14, 1.0, and 1.1.x.

So, what exactly is the problem? Is it an SQL injection hole, or are the RoR developers are just adding red herrings?

Either way, this isn’t looking good for the RoR team. Not because there is a security flaw, but rather because of how it’s being handled. I’m not the only one expecting some backlash over this.

Oh well, as David Heinemeier Hansson himself has said:

There’s no need to fear. Security is not likely to ever be a bullet point on the feature list of a framework. All Rails does is provide you with a number of features to _help_ deal with security, like SQL injection…

Heh.

Update: Kristian Köhntopp looked into the Mandatory Mystery Patch and appears to have found a flaw by running a diff on 1.1.4 vs. 1.1.5.

Lots of people are talking about the latest Django vs. Ruby on Rails vs. Symfony benchmarks. It’s the two sentence summary that seems to be getting the most attention:

Summary

Rails performed much better than Symfony. And Django performed much better than Rails.

More at the Django Weblog and from Ian Holsman. You can also check out some other benchmarks.

Hrm… it seems like webhosts are starting to support Ruby on Rails. First (well, not “first” but you know what I mean) GoDaddy, and now stories like this:

I can finally start developing for Ruby on Rails. Mmm. I picked up the second edition of the PickAxe book from the library and have been reading through it. Blocks are pretty darn cool. For the past couple of weeks I’ve been reading up on Python, and I’m pleased to find that most of the cool things that I like about Python are in Ruby.

Is it possible that the Python community missed the boat on this one?

This is good news for the Ruby users out there:

“Our customers are finding Ruby on Rails to be incredibly valuable in shaping their online presence,” said Bob Parsons, GoDaddy.com CEO and Founder. “We are pleased to be able to offer support for a framework that increases the utility of the sites we host.”

Also notable is the fact that they are offering Python CGI on some of their plans as well.

Via: John Collins

Ned Batchelder has been using Django at work for a while, but has determined that Ruby on Rails is the winner when it comes to web frameworks. He gives some rather convincing reasons for the switch.

I’m sure the post date of April 1, 2006 has no relation to the post.

Bones has been dabbling with RoR and has posted his some thoughts about using it, including a good comparison of RoR vs. Django. To me, it sounds like a fair assessment of both frameworks.

Here’s an example:

Well, I can confirm that the Rails scaffolding doesn’t really compete with Django’s ability to generate a first-approximation admin interface. I can also confirm that Rails really pushes the testing line in a way that is very pleasing to me. I’d say that Rails goes a bit beyond that, however, in that it creates project layouts that feel — to me at least — far more like working robust development environments than the Django setup.

He says he’s not giving up on Django, but he will be going to RoR for now.

On a sort of related note (re: RoR love), Bruce Kroeze says he’s jealous of the Ruby on Rails 1.1 release.

Eweek says that Ruby on Rails is poised to overtake Java as the language of choice for the web:

However, the non-Java Ruby on Rails, which is based on the Ruby dynamic language, has posed perhaps the biggest threat to Java development on the Web tier.

And perhaps the biggest Java “pressure-izer” is David Heinemeier Hansson, the creator of Ruby on Rails, who shared his thoughts on the new development landscape with eWEEK.

David does note in the article that while lots of people are using RoR in some way, it would appear that very few are using it in true production environments. But I would guess that if lots of new/younger programmers are playing with RoR in their spare time, eventually it will start showing up in a big way in IT departments as those people get hired and move up.

After a slight delay, the long awaited Basecamp API is now available. The documentation is a little on the light side, but rather straightforward. They give some examples using curl and some Ruby code to get you started. Remember that you have to explicitly enable the API for your account before it will work.

I tried some of the examples. You basically get XML responses that look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<company>
  <name>Thinkhole Labs</name>
  <city></city>
  <zip></zip>
  <phone-number-office></phone>
  <phone-number-fax></phone>
  <country>United States</country>
  <id type="integer">235827</id>
  <address-two></address>
  <can-see-private type="boolean">true</can>
  <web-address>http://thinkhole.org</web>
  <url-name>thinkhole</url>
  <address-one></address>
  <time-zone-id>Eastern Time (US &amp; Canada)</time>
  <state></state>
</company>

So the question is, who will be the first person to make a nice Python module that handles the API in its entirety? I would imagine it won’t be long before you’ll be able to put ‘import basecamp’ at the top of your script.

I think having an open API will get a lot more people to look at their product. A very good move on their part if you ask me. Of course, 37Signals does reserve the right to “modify or discontinue, temporarily or permanently, your access to the API (or any part thereof) with or without notice.”

Ah… the joy of not owning your own applications!

Update: Here’s the announcement on the SvN blog and the API forum.

Quoth Jason Fried on 3/18:

It was supposed to launch tonight at 10pm CST. We may have to push it back a week though for some additional testing. We’ll let everyone know when it’s launched. Stay tuned. Until then there’s nothing more we can share about it.

General consensus was that the Basecamp API would be ready to rock last weekend, but that obviously never happened. My guess is that we’ll see it before the end of the month.

Update: In response to a question about where the documentation will be posted: “There’s no answer to [that question] because there is no API yet. We’ll post everything when we release it. Until then there’s nothing we can tell you or share.” Heh, well ok then!