Rails 2.0 Released
weblog.rubyonrails.org
weblog.rubyonrails.org
Action Pack: Cookie store sessions
The default session store in Rails 2.0 is now a cookie-based one. That means sessions are no longer stored on the file system or in the database, but kept by the client in a hashed form that can't be forged. This makes it not only a lot faster than traditional session stores, but also makes it zero maintenance. There's no cron job needed to clear out the sessions and your server won't crash because you forgot and suddenly had 500K files in tmp/session.
This setup works great if you follow best practices and keep session usage to a minimum, such as the common case of just storing a user_id and a the flash. If, however, you are planning on storing the nuclear launch codes in the session, the default cookie store is a bad deal. While they can't be forged (so is_admin = true is fine), their content can be seen. If that's a problem for your application, you can always just switch back to one of the traditional session stores (but first investigate that requirement as a code smell).
Unfortunately, I can't seem to find it anymore.
If you look at the code, the session store is stored in plaintext with the hash. Rails rehashes the plaintext in the cookie and checks it against the hash to make sure it has not been tampered with. The last time I checked, the hashing uses OpenSSL's HMAC hashing rather than the SHA1 in earlier versions of Rails.
You, as the developer, are responsible for entering in the site's secret code. It should be possible to write a Rails 2.0 initializer in config/intializer to check the presence of config/secret.yml and if not, generate it in runtime. This keeps you from having to save the secret in the version control, but unfortunately, doesn't work well when you deploy it across several machines.
Note that the cookie store was available in 1.2. Seems as if the core developers like it enough to enable it by default. As for me, I think I'll stick with ActiveStore for a while until my sites needs more drastic means, such as memcached or even cookie store.
A big part about Rails2 is also to take the cruft out of the framework. In other words, moving things out into plugins and cleaning up the core.
I don't do a lot of AJAXy stuff, and I don't talk very frequently to clients that aren't standard browswers. If I did, I think I would have a lot more to gain from this release.
As for the questions about the lack of "scalability" improvements, I don't really care. Its not needed for what I use it for anyway (and probably the same for most people).
Between this and Ruby 1.9 there's some fun new stuff for RoR folks to play with.
The 2.0 release may be coming in close with the upcoming Ruby 2.0 release, which will be highly disruptive (YARV bytecode backend), though I'm not sure if Rails 2.0 will work fine without any changes in Ruby 2.0. Besides, I'm not really sure when Ruby 2.0 is coming out.