[ANN] Radiant 0.6.5 Release Candidate 1

Ruby Apps Radiant CMS
1

Radiant 0.6.5 has been a long time coming! And just to be sure, we want
to release a candidate or two to make sure we have everything solid.
There are some really major changes in this release, and here’s the two
big ones:

  • Rails 2.0.2 included
  • RSpec is used in core and supported in extensions

You can download the Radiant 0.6.5 RC1 from
http://radiantcms.org/downloads/radiant-0.6.5-RC1.gem.

This release candidate is intended for developers and is NOT intended
for production use. Please report any bugs you find to the development
site at http://dev.radiantcms.org/.

== Installation

To install use the gem command (with ‘sudo’ as necessary):

$ gem install radiant-0.6.5-RC1.gem

The gem will install as ‘radiant-0.6.5’.

=== Upgrading an existing project/site

  1. Change the RADIANT_GEM_VERSION constant in config/environment.rb to
    “0.6.5”

  2. Update the Radiant assets in your project:

$ rake radiant:update

  1. Copy your customizations back into config/environment.rb, if
    necessary (see below).

  2. Migrate the database if you are running 0.6.2 or earlier:

$ rake production db:migrate

  1. Restart the server

=== Creating a new project/site

  1. Invoke the ‘radiant’ command with your desired database driver:

$ radiant -d sqlite3 my_project

  1. Bootstrap the database:

$ cd my_project
$ rake db:bootstrap

  1. Startup the server and try it out!

$ script/server

== Internal Changes to config/environment.rb

This release has required a lot of changes to the internal API of
Radiant. End-users should be unaffected, but as a result of these
requirements, we have made significant changes to config/environment.rb
and config/boot.rb. When updating your existing projects,
config/environment.rb will be copied to config/environment.bak. You
will need to manually copy any customizations, especially
config.extensions and any other libraries, etc. that you require. DO
NOT copy config.load_paths, config.plugin_paths, or any of those items
to the new file; those settings have been internalized in this release.

Thanks again for everyone’s contributions!

Cheers,

Sean

2

Yay!!!

3

On Tue, Feb 26, 2008 at 6:51 AM, Sean C. [email protected]
wrote:

Radiant 0.6.5 has been a long time coming! And just to be sure, we want
to release a candidate or two to make sure we have everything solid.
There are some really major changes in this release, and here’s the two
big ones:

  • Rails 2.0.2 included

Is this new version of radiant going to use the Rails 2 new CSRF
protection system?. In the SVN trunk I can only see this feature
explictly disabled on test enviroment (config/enviroments/test.rb#27)
and since the application.rb is still unchanged (with no
protect_from_forgery as in the new Rails2 apps) that suggest me that
the CSRF measures are going disabled.

I know radiant’s forms are mostly handmaded without helpers (same for
the ajax processes) and that enabling the anti-forgery measures will
break a few forms/views. So… what is your view about this?. I’ll
gladly submit the needed patches if finally we go with the protected
version (even if this go fot the 0.6.6… ).

Last but by no means least… thanks to the radiant community for
this great software and to all the commiters for this new version.

–
Kind Regards,
Aitor Garcia
Cofounder - Linking Paths
http://www.linkingpaths.com

4

On Tue, Feb 26, 2008 at 6:51 AM, Sean C. [email protected]
wrote:

Radiant 0.6.5 has been a long time coming! And just to be sure, we
want
to release a candidate or two to make sure we have everything solid.
There are some really major changes in this release, and here’s the
two
big ones:

  • Rails 2.0.2 included

Is this new version of radiant going to use the Rails 2 new CSRF
protection system?. In the SVN trunk I can only see this feature
explictly disabled on test enviroment (config/enviroments/test.rb#27)
and since the application.rb is still unchanged (with no
protect_from_forgery as in the new Rails2 apps) that suggest me that
the CSRF measures are going disabled.

I know radiant’s forms are mostly handmaded without helpers (same for
the ajax processes) and that enabling the anti-forgery measures will
break a few forms/views. So… what is your view about this?. I’ll
gladly submit the needed patches if finally we go with the protected
version (even if this go fot the 0.6.6… ).

Last but by no means least… thanks to the radiant community for
this great software and to all the commiters for this new version.

–
Kind Regards,
Aitor Garcia
Cofounder - Linking Paths
http://www.linkingpaths.com

5

Aitor,

We will need to investigate what it takes to use this. It may have to
delay until the next release if it requires changing a lot of view
code. Also, what are the risks of leaving it out? I’m not aware of
what it specifically protects.

Sean

6

Aitor,

Ok, I get it now. However, this seems like something best left for
0.6.6 (which should be a shorter turnaround to release). We will be
normalizing all of the admin controllers to be RESTful, and need to
address the correct verbs anyway. Also, be aware that simply loading
“/admin/pages/remove/1” will give you a confirmation page. We don’t
currently have any actions that do something destructively via GET.

Sean

7

On Mon, Mar 3, 2008 at 9:48 PM, Sean C. [email protected]
wrote:

Ok, I get it now. However, this seems like something best left for
0.6.6 (which should be a shorter turnaround to release). We will be
normalizing all of the admin controllers to be RESTful, and need to
address the correct verbs anyway.
Ok.

Also, be aware that simply loading
“/admin/pages/remove/1” will give you a confirmation page.
Oops… I forgot the confirmation page… anyway the CSRF issue works
with POST actions.

We don’t
currently have any actions that do something destructively via GET.

But we have actions that don’t change state done via POST (like the
get the childs action cited priorly), which is a misleading way to
perform these actions, specially with this CSRF issue and the technic
used by the rails helpers.

–
Kind Regards,
Aitor Garcia
Cofounder - Linking Paths
http://www.linkingpaths.com

8

On Mon, Mar 3, 2008 at 6:20 PM, Sean C. [email protected]
wrote:

Aitor,

We will need to investigate what it takes to use this. It may have to
delay until the next release if it requires changing a lot of view
code. Also, what are the risks of leaving it out? I’m not aware of
what it specifically protects.

The CRSF attacks are based in the trust your applications give to the
authenticated users. Basically allows an attacker perform actions on
your site like an authenticated user. If the victim has logged in your
site and later navigate to a malicious page with the following
content:

his browser will send the request (and the needed cookie to
authenticate it) to radiant_installation, eventually deleting the home
of the radiant instance. For more info just check:
Cross-site request forgery - Wikipedia.

The first step would be to use the correct HTTP verbs for each action,
delimiting the safe ones (think GETs). In this context and just like
an example SiteMap.getBranch() in sitemap.js is getting the childs of
a page with a POST request. Since this action is just returning info
without changing any state on the server a simple it’d better
acomplished with a GET request. Once the real POST/PUT/DELETE have
been determined we can focus on protect them.

To do this and with the CSRF protection enabled, rails form/view/ajax
helpers will emit a secret_token that is generated by a combination of
the user’s session id and some pre-determined server secret. In the
words of Rick O., the creator of the original plugin later mixed in
the core:

“The idea is that a compromised page may be able to get your session
id, but would have no way of generating the correct token without
knowing the server secret.”

As commented in the first mail radiant’s forms are mostly handmaded
without helpers so we need to modify them to use the helpers o
manually put the authentication token for server validation. Finally
we could enable the protection on Admin::AbstractModelController with
something like:

class Admin::AbstractModelController < ActionController::Base
protect_from_forgery
end

One more time I’d gladly help in these prosaic tasks XD.

–
Kind Regards,
Aitor Garcia
Cofounder - Linking Paths
http://www.linkingpaths.com