# \[ANN\] Radiant 0.6.5 Release Candidate 1 **URL:** \ **Category:** Radiant CMS\ **Created:** [February 26, 2008, 6:52am UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188 "2008-02-26T06:52:07Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [February 26, 2008, 6:52am UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/1 "2008-02-26T06:52:07Z")
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](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/](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 ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [February 27, 2008, 9:33pm UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/2 "2008-02-27T21:33:36Z")
Yay!!! ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [February 27, 2008, 9:37pm UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/3 "2008-02-27T21:37:53Z")
On Tue, Feb 26, 2008 at 6:51 AM, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://www.linkingpaths.com) ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 3, 2008, 6:12pm UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/4 "2008-03-03T18:12:38Z")
On Tue, Feb 26, 2008 at 6:51 AM, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://www.linkingpaths.com) ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 3, 2008, 6:22pm UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/5 "2008-03-03T18:22:06Z")
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 ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 3, 2008, 9:49pm UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/6 "2008-03-03T21:49:46Z")
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 ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 3, 2008, 10:26pm UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/7 "2008-03-03T22:26:29Z")
On Mon, Mar 3, 2008 at 9:48 PM, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://www.linkingpaths.com) ---
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [March 3, 2008, 9:33pm UTC](https://www.ruby-forum.com/t/ann-radiant-0-6-5-release-candidate-1/130188/8 "2008-03-03T21:33:12Z")
On Mon, Mar 3, 2008 at 6:20 PM, Sean C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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: ![](http://radiant_installation/admin/page/remove/1) 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](http://en.wikipedia.org/wiki/Cross-site_request_forgery). 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](http://www.linkingpaths.com)