

Rails 2.0 Released - carpal
http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

======
kingnothing
Does anyone have anything to add about the security of this:

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).

~~~
qaexl
Yeah. There was a discussion about it in an earlier thread.

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.

~~~
carpal
Heres the thread:

<http://news.ycombinator.com/item?id=81932>

------
russ
Nice summary for you: <http://blog.viget.com/whats-coming-in-rails-20/>

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.

------
icey
A 2.0 release seems like a big deal; is there a rails practitioner around who
could describe the magnitude of these changes to those of us who don't use
rails?

~~~
carpal
I've been developing off of the preview releases for a few weeks, and there's
nothing earth shattering. Generally, it just makes things nicer.

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.

~~~
michaelneale
That is probably a good thing. Rails is a great fit for what it does, a 2.0
danger was to do beyond its strengths. It seems to have evolved nicely. I look
forward to using it.

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).

------
hello_moto
I'm seeing "Agile Web Development with Rails 3rd Edition" coming out soon!

------
mattmaroon
I know we're pretty excited. Performance is going to be a major issue for us
once we get into providing live stats for people. We'll see how this helps.

------
nanijoe
Its already 2.01 !!!

