[ANN] Rails 3.0.8.rc1

ZOMG HI EVERYBODY!!!! HAPPY WEDNESDAY (UTC-7).

I am EXCITED, PLEASED, and even MORE EXCITED to announce the release of the Rails 3.0.8 released candidate NUMBER ONE!

OMG RELEASE CANDIDATE. WHAT DOES IT MEAN?

This is a release candidate! It means that we (the rails core team) are asking you (our lovely users) to test out the code that we’d like to release!

This is your chance to VETO our release of Rails 3.0.8 final!

VETO?? WHY WOULD I DO THAT?

Well you see, dear public, let me explain. In order to bring you this latest and greatest released of rails, we’ve made bug fixes and changed codes. Unfortunately, that means that we may have inadvertently broken your application. We don’t want to break your application, we want to fix bugs!

This is your chance to try our the release candidate and let us know if we’ve broken your application!

HOW DO I TEST YOUR WONDERFUL AND AMAZING RELEASE CANDIDATE?

Very simple! If you’re using bundler, just update your Gemfile to point at rails version ‘3.0.8.rc1’. Then do a bundle update, and you’re off to the races! Make sure your application behaves normally, all your tests pass, etc.

I think I’ve found a boog! How do I veto???

It’s easy, breezy, beautiful, to veto! Just reply to this on the rails-core mailing list, and let us know what went wrong! We’ll fix the problem and cut another release candidate.

Make sure to check that your failure does not occur on Rails 3.0.7, but does occur on the release candidate. If the failure is also on 3.0.7, we still want to know! It just won’t block our release.

TELLME THE CHANGES YOU’VE MADE!

Ok, just calm down. For now, go check out this link on github.

Or go check out the CHANGELOG files in each project. When we release the final, I’ll add the changelog to the announce email.

WHEN WILL THE FINAL RELEASE BE??? TELL ME NOW!!!

Typically we release the final version 72 hours after the release candidate. But this weekend is a holiday, so I don’t feel like doing a release this weekend. Instead, I will target the final to be released on May 31st.

If we find show stopping bugs, we’ll release another RC and the 72hour counter will reset!

WHY AREN’T YOU RELEASING ON THE WEEKEND? COMMON, BRO.

What?!?! Why aren’t you releasing on the weekend??? I’m going to be making sausage. :-P

Thanks everybody!!!!

<3 <3 <3 <3 <3 <3

Rails 3.1: Release candidate

As I promised at RailsConf, we’re finally good to go on the Rails 3.1: Release Candidate. This is a fantastically exciting release. We have three new star features and an even greater number of just awesome improvements. First the stars:

The Asset Pipeline
The star feature of 3.1 is the asset pipeline powered by Sprockets 2.0. It makes CSS and JavaScript first-class code citizens and enables proper organization, including use in plugins and engines. See my RailsConf keynote for a full tour. This comes with SCSS as the default for stylesheets and CoffeeScript as the default for JavaScript. Much documentation is on the way for this.

HTTP Streaming
This lets the browser download your stylesheet and javascripts while the server is still generating the response. The result is noticeable faster pages. It’s opt-in and does require support from the web server as well, but the popular combo of nginx and unicorn is ready to take advantage of it. There’s a great Railscast on HTTP streaming and the API documentation is strong too.

jQuery is now the default
We’ve made jQuery the default JavaScript framework that ships with Rails, but it’s silly easy to switch back to Prototype if you fancy. It’s all bundled up in the jquery-rails and prototype-rails gems. Just depend on the one you’d like in the Gemfile and it’ll Just Work.

Other good stuff:

  • Reversible migrations: DRY migrations that know how to revert themselves. Cleaner, nicer migrations.
  • Mountable engines: Engines can now have their own routing and helper scope. They can also take advantage of the asset pipeline (more documentation on this soon). Read the story behind mountable engines (even if the asset stuff is now out of date).
  • Identity Map: It’s not enabled by default because of some important caveats that are still to be ironed out, but if you can deal with those, it’s a great way to cut down on the number of queries your app will trigger. Faster is better!
  • Prepared statements: Active Record now uses cached prepared statements, which is a big boost for PostgreSQL in all cases and a boost for MySQL on complex statements.
  • Rack::Cache on by default: This makes it possible to use HTTP caching with conditional get as a replacement for page caching (which we’ll soon factor into a plugin and remove from core).
  • Turn test-output on Ruby 1.9: Much nicer test output courtesy of the Turn gem. It’s on with new applications by default on Ruby 1.9.
  • Force SSL: It’s now easier than ever to keep your app safe with force_ssl. Either per-app or per-controller.
  • Role-based mass-assignment protection: attr_protected now accepts roles, so it’s easier do deal with admin/non-admin splits and more.
  • has_secure_password: Dead-simple BCrypt-based passwords. Now there’s no excuse not to roll your own authentication scheme.
  • Custom serializers: Serialize objects with JSON or whatever else you’d like.

You can also check out the an even longer changelog and get a video overview from Railscast.

If you’re starting a new application, it’s strongly recommended that you do so using Ruby 1.9.2. Rails will continue to support 1.8.x until Rails 4.0, but it’s considered the legacy option. Ruby 1.9.x is where the action is. Get on board and enjoy the massive speed boost.

You can install the Rails 3.1: Release Candidate with gem install rails --pre. Enjoy and report any release candidate issues on Github. We expect to release the final version in a couple of weeks if all goes well.

Rails 3.1 beta 1 released

We’ve taken our first release step towards the final version of Rails 3.1 today with the unveiling of beta 1. This is a release mostly for people who’ve already been following along with the development of Rails 3.1 and want to try a version that’s close to feature complete.

We do not yet have all the documentation ready, so it’s still a bit of a detective job to figure out how it all fits together. Thus, this is not a general release and I wont hold it against you if you’re holding out for a release candidate (coming in the next few weeks).

The tag is 3.1.0.beta1 and you can install using gem install rails --pre. Enjoy!

jQuery: New Default

In Rails 3.1 jQuery is going to be the default JavaScript library. Also, RJS has been extracted out. This post explains what that means for new applications, and what to look for while upgrading existing applications.

New Applications

Starting with Rails 3.1

rails new my_app

generates an application with jQuery.

The -j option of the generator lets you choose Prototype and Scriptaculous instead:

rails new my_app -j prototype

Such an application does not have RJS yet available though. From now on prototype-rails is needed for RJS, see below.

Upgrading Applications Using No RJS

Existing applications using no RJS should remove any references to ActionView::Base.debug_rjs in the project. Typically that means deleting

config.action_view.debug_rjs = true

from config/environments/development.rb. Other than that, upgrading should work out of the box as far as these changes is concerned.

Upgrading Applications Using RJS

Existing application using RJS should work out of the box with prototype-rails.

prototype-rails

RJS has been extracted to prototype-rails.

Applications using RJS have to add this line to their Gemfile while working against Rails master before the 3.1 release:

gem 'prototype-rails', :git => 'git://github.com/rails/prototype-rails.git'

prototype-rails is gonna be a gem when Rails 3.1 is out.

prototype-rails is the one who provides now the RJS template handler; the configuration flag ActionView::Base.debug_rjs; the ability to pass a block to link_to_function and button_to_function; the :update option of render, both in controllers and views; and the modules ActionView::Helpers::PrototypeHelper and ActionView::Helpers::ScriptaculousHelper.

Extraction has taken backwards compatibility into account as much as possible. With that goal in mind, everything is put back where it was before, either by reopening classes or modules, or via alias_method_chain when the refactor involved cutting some part of a method out, as happened with render :update.

There’s an exception: ActionView::Helpers::PrototypeHelper and ActionView::Helpers::ScriptaculousHelper are no longer ancestors of ActionView::Helpers. They are now injected into ActionView::Base and ActionView::TestCase directly.

When you include a module M into a class C, the class stores a proxy to M in its ancestor chain. After inclusion, if you add methods to M instances of C respond to them. But if you include another module N into M, the ancestor chain of C is not updated. Instances of C won’t respond to N’s methods. Although a complete dynamic method dispatch would treat both ways of augmenting M equal, that’s the way it works as of today.

By the time prototype-rails is loaded ActionView::Helpers has already been included into ActionView::Base and ActionView::TestCase, so we need to inject them directly where they are needed. Standard usage just works, but please take into account that change in case you reopened or used ActionView::Helpers assuming those ancestors.

Before release, prototype-rails is going to provide also a way to bring Prototype and Scriptaculous to any application.

One Last Detail: The xhr Test Helper

The xml_http_request/xhr test helper is a simple convenience method that sets the X\_REQUESTED\_WITH header to “XMLHttpRequest”. If the test request has no Accept header, a fixed value of

[Mime::JS, Mime::HTML, Mime::XML, 'text/xml', Mime::ALL].join(', ')

serves as default.

The Accept header in Prototype calls corresponds to that value, but in jQuery it depends on the dataType attribute. Also, in other JavaScript libraries the Accept header may behave differently. What to do with the default?

This method has been left as is. In particular, if your application uses jQuery the default Accept header in the test will be different from the Accept header sent by jQuery. That’s some vinegar: Rails encourages you to base interfaces on explicit format parameters. So, for example, best practice is to provide a /users.json endpoint, rather than a /users endpoint with a JSON representation chosen depending on the Accept header.

If you desperately need a matching Accept header in tests you are still able to pass it. And you can also write your own convenience test helpers easily, since a XHR request is just one whose X\_REQUESTED\_WITH header matches /XMLHttpRequest/i.

Try It Out!

If your application uses RJS it would be really helpful that you test it against master with prototype-rails and report any issues you may find. Thanks!

Rails 3.0.7 has been released!

Hello everyone! I’ve released Rails version 3.0.7!

I want to say thanks to Santiago for handling the release candidate gems. He’s on vacation, so I get to do the real thing.

The main change in this release is to fix a performance regression in ActiveRecord that was introduced in version 3.0.6.

Changes

For a web friendly view, check out the compare view on github.

For those that want the TL;DR of the commits, here are the pertinant CHANGELOG entries for each project:

activesupport

  • Hash.from_xml no longer loses attributes on tags containing only whitespace [André Arko]

activerecord

  • Destroying records via nested attributes works independent of reject_if LH #6006 [Durran Jordan]
  • Delegate any? and many? to Model.scoped for consistency [Andrew White]
  • Quote the ORDER BY clause in batched finds - fixes #6620 [Andrew White]
  • Change exists? so records are not instantiated - fixes #6127. This prevents after_find and after_initialize callbacks being triggered when checking for record existence. [Andrew White]
  • Fix performance bug with attribute accessors which only occurred on Ruby 1.8.7, and ensure we cache type-casted values when the column returned from the db contains non-standard chars. [Jon Leighton]
  • Fix a performance regression introduced here 86acbf1cc050c8fa8c74a10c735e467fb6fd7df8 related to read_attribute method [Stian Grytøyr]

actionmailer

  • remove AM delegating register_observer and register_interceptor to Mail [Josh Kalderimis]

Checksums

Just in case!

$ shasum *
6b96ed6cf0717e7e40b7ef9b39a70814d3928250  actionmailer-3.0.7.gem
c28009b6ce47c60553027c1ddd9c9bd2aacb2c82  actionpack-3.0.7.gem
6ee5ca84b460fff55e7dd825fc966cfbc4b36070  activemodel-3.0.7.gem
25ff07f49129ccd405c95047b41e6717e95f9471  activerecord-3.0.7.gem
a4adde3ad82017d8925e99733d1cd288b1474c39  activeresource-3.0.7.gem
d1a0192fd9da869caee79be66a5915633eda291f  activesupport-3.0.7.gem
04aa110f50d2ea9b8434526faff57ab2e249495e  rails-3.0.7.gem
9430747274afa4fac2c37ae05a39f9cb79680e16  railties-3.0.7.gem

Have a great week everyone!

<3 <3 <3 <3 <3

Why HTTP Streaming?

Rails 3.1 is going to support HTTP streaming, aka chunked responses, this post explains what’s all about.

What Is HTTP Streaming?

Ordinary dynamic HTTP responses need a Content-Length header. Their timeline look like this:

HTTP request -> dynamic content generation -> HTTP response

Those are three serial steps because normally you need to generate the content in order to be able to know its size, and thus fill the Content-Length header of the response.

HTTP provides an alternative to this schema to be able to flush data as it is produced, known as chunked transfer encoding. That’s what we are referring to as streaming in recent commits.

Streamed responses have no Content-Length header. Rather, they have a Transfer-Encoding header with a value of “chunked”, and a body consisting of a series of chunks you write to the socket preceded by their individual sizes. Modulus details.

This is an example taken from Wikipedia:

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

25
This is the data in the first chunk

1C
and this is the second one

3
con
8
sequence
0

Point is, you are able to flush chunks to the socket as soon as you have them, no need to wait for the whole thing to be generated.

When Do Web Browsers Fetch Assets?

Web broswers parse documents as their content is received. When they find an asset referenced, think an image, stylesheet, or script, a request to fetch them is fired. That happens in parallel while the document is being received and processed, no matter whether the content comes chunked or not.

Browsers have limits on the number of concurrent requests they are allowed to do, a global one (typically +30), and another per domain (nowadays typically 4 or 6), but within those limits, requests for getting assets happen as the content is parsed.

Modern clients do not even block on JavaScript files as old ones did, they implement scanners that look ahead for asset nodes and request them. For example, this is the preload scanner of WebKit.

Trivia: While investigating this I discovered by accident that if the MIME type is unclear, for example “text/html” without an explicit charset, then web browsers buffer 1 KB of data firing no asset requests to be able to peek at the content and do an educated guess.

So What’s The Benefit Of Streaming?

Streaming doesn’t cut latency, neither it cuts the time a dynamic response needs to be generated. But since the application sends content right away instead of waiting for the whole response to be rendered, the client is able to request assets sooner. In particular, if you flush the head of an HTML document CSS and JavaScript files are going to be fetched in parallel, while the server works on generating content. The consequence is that pages load faster.

Followup

Streaming is still being polished for Rails 3.1, expect another post in the future covering its practical aspects in Ruby on Rails applications.

Thanks

Tony Gentilcore provided his insider’s guidance into this, thank you very much Tony! Also, thanks a lot to the Browserscope project for their really useful tables.

Ruby Hero Awards 2011

Ruby Heroes

It’s that time again to take a moment to think about those who have impacted the Ruby community this year but have not received the recognition they deserve. We have given away eighteen awards in the past three years at Railsconf, and this year we are preparing to give away six more.

But we need your help.

So, if you know someone who has contributed greatly this year please take a moment to show some gratitude by nominating them on RubyHeroes.com. In two weeks the Ruby Heroes from last year will look at the nominations and decide who should receive the awards (this way there’s no popularity contest). However, your nominations do matter, so please take a moment and spread the gratitude.

The winners will be announced live on stage at Railsconf 2011.

Rails 3.0.6 has been released!

Hi everybody! Rails 3.0.6 has been released!

Let’s get the serious business out of the way first:

Rails 3.0.6 contains an important security fix! Please upgrade!

Rails versions 3.0.x prior to 3.0.6 contain an XSS vulnerability. The vulnerability manifests itself via the auto_link method. The auto_link method will automatically mark input strings as “html safe” even if the input is from an unknown origin.

For example:

<%= auto_link(params[:content]) %>

If the “content” parameter contains malicious javascript, that script will be rendered without being escaped.

How can I protect myself?

  • Upgrade to Rails 3.0.6, then content passed to auto_link will be automatically escaped for you.

  • If you cannot upgrade Rails, then apply the patch found here. Then auto_link content will be escaped for you.

  • If you cannot upgrade Rails, or apply the patch, then change your calls to auto_link to call sanitize like so:

    <%= sanitize(auto_link(params[:content])) %>

    If you trust the input, then change to this

    <%= raw(auto_link(params[:content])) %>

Credits

Thanks go to Torben Schulz for reporting this issue!

SERIOUS BUSINESS COMPLETE

After two release candidates, we we we so excited to announce the release of Rails version 3.0.6! I want to thank everyone that tried out the release candidates and reported their feedback! I hope that we can continue soliciting feedback from the public before releasing final versions.

LOL CHANGES!!!!

For changes in a particular package, please view the CHANGELOG in each particular project on github. Even better, you can check the compare view.

Changes of note are:

  • The above security fix in ActionPack 61ee3449674c591747db95f9b3472c5c3bd9e84d

  • Un-deprecating the reorder method in ActiveRecord 235a4142aa3fee73faa0f01e267a2b4254cea8ce

  • A backport of “cheaper attributes reads” in ActiveRecord 86acbf1cc050c8fa8c74a10c735e467fb6fd7df8

  • Correctling handling before_type_cast on timezone aware attributes 0823bbd757f3654a08d300e27873758da606f06a

  • Escaping binary data in sqlite3 inserts 7222786c15eacbd432b2bce9798d3f3459f7e05f

  • Fixing schema support for the mysql adapter eb1eac93151c1d45c3ef292d99bfcf74799185ea

This change list IS NOT exhaustive. They are just some of my favorites! For the complete list please see the CHANGELOG files or view the diff on github.

GEM CHECKSUMS

If you totally want to make sure that you’ve got the right gems, here are my shasums before I pushed the gems!

shasum *

  • fc7b0503bdf99d1ec08dc0dcee3677ca1dd29f0f actionmailer-3.0.6.gem
  • e8fbefd5b0a46408dd557331700ea514a4c199ab actionpack-3.0.6.gem
  • 8509520744ecd8e6712158311a16ba4782b454e2 activemodel-3.0.6.gem
  • 3b392e811ba342a5bf430d89cf4f060d119aba64 activerecord-3.0.6.gem
  • 9eea440bdf885e857ebfb5ff8e31119f76a18a4e activeresource-3.0.6.gem
  • 175ba6286f7802edeeaab30f900d87a38f516728 activesupport-3.0.6.gem
  • ebeea3c1f03db3309ea9a6640e1767ab144ff567 rails-3.0.6.gem
  • 61e24f94ea87fc58175b2067f7f6a3a8c468bfe0 railties-3.0.6.gem

IN CLOSING

Thank you for waiting for me to finish vacation before I released this! I hope that everyone enjoys this bugfix release of Rails. Next time I’ll try not to vacation so much! ;-)

<3 <3 <3 <3 <3

Rails 3.0.5 has been released!

Aaron Patterson showed us some tenderlove this week by releasing Rails 3.0.5. Have a peek at what got updated.

Bugs Fixed

  • Fix when gzip returns a UTF-8 string on Ruby 1.9, when it is actually binary. commit
  • Active Record limit values will not escape Arel SQL Literal nodes. commit
  • Relation#where calls will always produce AND statements regardless of how conditions hashes behaves (reverting 00693209ecc).
  • Observer callbacks will only be executed once when using STI classes in ActiveRecord. commit

Deprecations Added:

  • Deprecate Relation#& alias for Relation#merge. commit
  • Deprecated support for interpolated association conditions with the
    :conditions => ‘foo = #{bar}’ syntax, and added the new interpolation syntax
    which is :conditions => proc { “foo = #{bar}” }. commit

This is not a complete list of changes. The complete list of changes can be
found here

SHA1 Checksums:

  • actionmailer-3.0.5.gem b25750c8126aa21db27d7b0ee829b2e94e525ebc
  • actionpack-3.0.5.gem 0a6f7f9ac2960ff224c913877a2917e1bea80df3
  • activemodel-3.0.5.gem 1556900a7afa1cdcdf4641edbcdd2c24f98bb2de
  • activerecord-3.0.5.gem 33dd05d7362931564f6f15ea7130cc27a5fc09e8
  • activeresource-3.0.5.gem 758f893cbb7ef945c857bf4ca044b94017bdc437
  • activesupport-3.0.5.gem 195fa3f7fa044134703a655cdb906edb515286c4
  • rails-3.0.5.gem 32322bf9952d76c5fa0054c8533c0c58609f40aa
  • railties-3.0.5.gem 3dddf14736dec991c3dbbe2d89495613e72c19c7

CSRF Protection Bypass in Ruby on Rails

There is a vulnerability in Ruby on Rails which could allow an attacker to circumvent the CSRF protection provided. This vulnerability has been assigned the CVE Identifier CVE-2011-0447.

  • Versions Affected: 2.1.0 and above
  • Not affected: Applications which don’t use the built in CSRF protection.
  • Fixed Versions: 3.0.4, 2.3.11

Impact

Certain combinations of browser plugins and HTTP redirects can be used to trick the user’s browser into making cross-domain requests which include arbitrary HTTP headers specified by the attacker. An attacker can utilise this to spoof ajax and API requests and bypass the built in CSRF protection and successfully attack an application. All users running an affected release should upgrade or apply the patches immediately.

Releases

The 3.0.4 and 2.3.11 releases are available at the normal locations.

Upgrade Process

There are two major changes in this fix, the behaviour when CSRF protection fails has changed and the token will now be required for all non-GET requests.

After applying this patch failed CSRF requests will no longer generate HTTP 500 errors, instead the session will be reset. Users can override this behaviour by overriding handle_unverified_request in their own controllers.

Users must still take care that users cannot be auto logged in via non-session data. For example, an application using filters to implement ‘remember me’ functionality must either remove those cookies in their handle_unverified_request handlers or ensure that the remember me code is only executed on GET requests. A custom handler which removes the remember_me cookie would look like:

def handle_unverified_request super # call the default behaviour which resets the session cookies.delete(:remember_me) # remove the auto login cookie so the fraudulent request is rejected. end

There are two steps to ensuring that your application sends the CSRF Token with every ajax request. Providing the token in a meta tag, then ensuring your javascript reads those values and provides them with each request. The first step involves you including the csrf_meta_tag helper somewhere in your application’s layout. Rails 3 applications likely already include this helper, however it has now been backported to the 2.3.x series. An example of its use would be something like this in application.html.erb:

<%= javascript_include_tag :defaults %> <%= csrf_meta_tag %>

In addition to altering the templates, an application’s javascript must be changed to send the token with Ajax requests. Rails 3 applications can just update their rails.js file using rake rails:update, 2.x applications which don’t use the built-in ajax view helpers will need to add a framework-specific snippet to their application.js. Examples of those snippets are available:

Workarounds

There are no feasible workarounds for this vulnerability.

Patches

To aid users who aren’t able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format, 3-0-csrf.patch includes two changesets, the others consist of a single changeset.

Given the severity of the problem we are also providing backported fixes to the 2.2 and 2.1 series. There will be no gem releases for these versions but the stable branches in git will be updated.

Please note that only the 2.3.x and 3.0.x series are supported at present. Users of earlier unsupported releases are advised to upgrade as soon as possible as we cannot guarantee continued security fixes indefinitely.

Credits

Thanks to Felix Gröbert of the Google Security Team for reporting the vulnerability to us and working with us to ensure that the fix didn’t introduce any new issues. Thanks also to the Shopify development team for their assistance in verifying the fix and the upgrade process. The original vulnerability has been reported to vendors by kuza55