@@ -655,6 +654,18 @@ Lead Contributor: <a href="http://blog.hasmanythrough.com">Josh Susser</a>
...
@@ -655,6 +654,18 @@ Lead Contributor: <a href="http://blog.hasmanythrough.com">Josh Susser</a>
Lead Contributor: Adam Milligan
Lead Contributor: Adam Milligan
</p>
</p>
</li>
</li>
<li>
<p>
More information:
</p>
<divclass="ilist"><ul>
<li>
<p>
<ahref="http://afreshcup.com/2008/10/24/rails-22-change-private-methods-on-association-proxies-are-private/">Rails 2.2 Change: Private Methods on Association Proxies are Private</a>
</p>
</li>
</ul></div>
</li>
</ul></div>
</ul></div>
<h3id="_other_activerecord_changes">5.6. Other ActiveRecord Changes</h3>
<h3id="_other_activerecord_changes">5.6. Other ActiveRecord Changes</h3>
<divclass="para"><p>would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities.</p></div>
<divclass="para"><p>would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities.</p></div>
<divclass="para"><p>If you’d like more details on REST as an architectural style, these resources are more approachable than Fielding’s thesis:</p></div>
<divclass="ilist"><ul>
<li>
<p>
<ahref="http://www.infoq.com/articles/rest-introduction">A Brief Introduction to REST</a> by Stefan Tilkov
</p>
</li>
<li>
<p>
<ahref="http://bitworking.org/news/373/An-Introduction-to-REST">An Introduction to REST</a> (video tutorial) by Joe Gregorio
</p>
</li>
<li>
<p>
<ahref="http://en.wikipedia.org/wiki/Representational_State_Transfer">Representational State Transfer</a> article in Wikipedia
</p>
</li>
</ul></div>
</div>
</div>
<h2id="_creating_a_new_rails_project">3. Creating a New Rails Project</h2>
<h2id="_creating_a_new_rails_project">3. Creating a New Rails Project</h2>
<tdclass="content">Sharp-eyed readers will have noticed that the <tt>form_for</tt> declaration is identical for the <tt>create</tt> and <tt>edit</tt> views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a <em>partial template</em>, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that’s easy to modify if you want different forms for <tt>create</tt> and <tt>edit</tt>.</td>
<tdclass="content">Sharp-eyed readers will have noticed that the <tt>form_for</tt> declaration is identical for the <tt>new</tt> and <tt>edit</tt> views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a <em>partial template</em>, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that’s easy to modify if you want different forms for <tt>create</tt> and <tt>edit</tt>.</td>
</tr></table>
</tr></table>
</div>
</div>
<h3id="_destroying_a_post">6.12. Destroying a Post</h3>
<h3id="_destroying_a_post">6.12. Destroying a Post</h3>
<divclass="para"><p>The <tt>destroy</tt> method of an Active Record model instance removes the corresponding record from the database. After that's done, there isn't any record to display, so Rails redirects the user's browser to the index view for the model.</p></div>
<divclass="para"><p>The <tt>destroy</tt> method of an Active Record model instance removes the corresponding record from the database. After that's done, there isn't any record to display, so Rails redirects the user's browser to the index view for the model.</p></div>
</div>
</div>
<h2id="_adding_a_second_model">7. Adding a Second Model</h2>
<h2id="_drying_up_the_code">7. DRYing up the Code</h2>
<divclass="sectionbody">
<divclass="para"><p>At this point, it’s worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use <em>partials</em> to clean up duplication in views and <em>filters</em> to help with duplication in controllers.</p></div>
<h3id="_using_partials_to_eliminate_view_duplication">7.1. Using Partials to Eliminate View Duplication</h3>
<divclass="para"><p>As you saw earlier, the scaffold-generated views for the <tt>new</tt> and <tt>edit</tt> actions are largely identical. You can pull the shared code out into a <tt>partial</tt> template. This requires editing the new and edit views, and adding a new template:</p></div>
<divclass="para"><p>Now, when Rails renders the <tt>new</tt> or <tt>edit</tt> view, it will insert the <tt>_form</tt> partial at the indicated point. Note the naming convention for partials: if you refer to a partial named <tt>form</tt> inside of a view, the corresponding file is <tt>_form.html.erb</tt>, with a leading underscore.</p></div>
<divclass="para"><p>For more information on partials, refer to the <ahref="../layouts_and_rendering.html">Layouts and Rending in Rails</a> guide.</p></div>
<h3id="_using_filters_to_eliminate_controller_duplication">7.2. Using Filters to Eliminate Controller Duplication</h3>
<divclass="para"><p>At this point, if you look at the controller for posts, you’ll see some duplication:</p></div>
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>Four instances of the exact same line of code doesn’t seem very DRY. Rails provides <em>filters</em> as a way to address this sort of repeated code. In this case, you can DRY things up by using a <tt>before_filter</tt>:</p></div>
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>Rails runs <em>before filters</em> before any action in the controller. You can use the <tt>:only</tt> clause to limit a before filter to only certain actions, or an <tt>:except</tt> clause to specifically skip a before filter for certain actions. Rails also allows you to define <em>after filters</em> that run after processing an action, as well as <em>around filters</em> that surround the processing of actions. Filters can also be defined in external classes to make it easy to share them between controllers.</p></div>
<divclass="para"><p>For more information on filters, see the <ahref="actioncontroller_basics.html">Action Controller Basics</a> guide.</p></div>
</div>
<h2id="_adding_a_second_model">8. Adding a Second Model</h2>
<divclass="sectionbody">
<divclass="sectionbody">
<divclass="para"><p>Now that you've seen what's in a model built with scaffolding, it's time to add a second model to the application. The second model will handle comments on blog posts.</p></div>
<divclass="para"><p>Now that you've seen what's in a model built with scaffolding, it's time to add a second model to the application. The second model will handle comments on blog posts.</p></div>
<h3id="_generating_a_model">7.1. Generating a Model</h3>
<h3id="_generating_a_model">8.1. Generating a Model</h3>
<divclass="para"><p>Models in Rails use a singular name, and their corresponding database tables use a plural name. For the model to hold comments, the convention is to use the name Comment. Even if you don't want to use the entire apparatus set up by scaffolding, most Rails developers still use generators to make things like models and controllers. To create the new model, run this command in your terminal:</p></div>
<divclass="para"><p>Models in Rails use a singular name, and their corresponding database tables use a plural name. For the model to hold comments, the convention is to use the name Comment. Even if you don't want to use the entire apparatus set up by scaffolding, most Rails developers still use generators to make things like models and controllers. To create the new model, run this command in your terminal:</p></div>
<divclass="listingblock">
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>Active Record associations let you declaratively quantify the relationship between two models. In the case of comments and posts, you could write out the relationships this way:</p></div>
<divclass="para"><p>Active Record associations let you easily declare the relationship between two models. In the case of comments and posts, you could write out the relationships this way:</p></div>
<tdclass="content">For more information on Active Record associations, see the <ahref="../association_basics.html+">Active Record Associations</a> guide.</td>
<tdclass="content">For more information on Active Record associations, see the <ahref="../association_basics.html">Active Record Associations</a> guide.</td>
</tr></table>
</tr></table>
</div>
</div>
<h3id="_adding_a_route">7.3. Adding a Route</h3>
<h3id="_adding_a_route">8.3. Adding a Route</h3>
<divclass="para"><p><em>Routes</em> are entries in the <tt>config/routes.rb</tt> file that tell Rails how to match incoming HTTP requests to controller actions. Open up that file and find the existing line referring to <tt>posts</tt>. Then edit it as follows:</p></div>
<divclass="para"><p><em>Routes</em> are entries in the <tt>config/routes.rb</tt> file that tell Rails how to match incoming HTTP requests to controller actions. Open up that file and find the existing line referring to <tt>posts</tt>. Then edit it as follows:</p></div>
<divclass="listingblock">
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<tdclass="content">For more information on routing, see the <ahref="../routing_outside_in">Rails Routing from the Outside In</a> guide.</td>
<tdclass="content">For more information on routing, see the <ahref="../routing_outside_in">Rails Routing from the Outside In</a> guide.</td>
</tr></table>
</tr></table>
</div>
</div>
<h3id="_generating_a_controller">7.4. Generating a Controller</h3>
<h3id="_generating_a_controller">8.4. Generating a Controller</h3>
<divclass="para"><p>With the model in hand, you can turn your attention to creating a matching controller. Again, there's a generator for this:</p></div>
<divclass="para"><p>With the model in hand, you can turn your attention to creating a matching controller. Again, there's a generator for this:</p></div>
<divclass="listingblock">
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>This creates a new <tt>Comment</tt> object <em>and</em> sets up the <tt>post_id</tt> field to have the <tt>id</tt> from the specified <tt>Post</tt> object in a single operation.</p></div>
<divclass="para"><p>This creates a new <tt>Comment</tt> object <em>and</em> sets up the <tt>post_id</tt> field to have the <tt>id</tt> from the specified <tt>Post</tt> object in a single operation.</p></div>
<h3id="_building_views">7.5. Building Views</h3>
<h3id="_building_views">8.5. Building Views</h3>
<divclass="para"><p>Because you skipped scaffolding, you'll need to build views for comments "by hand." Invoking <tt>script/generate controller</tt> will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.</p></div>
<divclass="para"><p>Because you skipped scaffolding, you'll need to build views for comments "by hand." Invoking <tt>script/generate controller</tt> will give you skeleton views, but they'll be devoid of actual content. Here's a first pass at fleshing out the comment views.</p></div>
<divclass="para"><p>Again, the added complexity here (compared to the views you saw for managing comments) comes from the necessity of juggling a post and its comments at the same time.</p></div>
<divclass="para"><p>Again, the added complexity here (compared to the views you saw for managing comments) comes from the necessity of juggling a post and its comments at the same time.</p></div>
<h3id="_hooking_comments_to_posts">7.6. Hooking Comments to Posts</h3>
<h3id="_hooking_comments_to_posts">8.6. Hooking Comments to Posts</h3>
<divclass="para"><p>As a final step, I'll modify the <tt>show.html.erb</tt> view for a post to show the comments on that post, and to allow managing those comments:</p></div>
<divclass="para"><p>As a final step, I'll modify the <tt>show.html.erb</tt> view for a post to show the comments on that post, and to allow managing those comments:</p></div>
<divclass="listingblock">
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>Note that each post has its own individual comments collection, accessible as <tt>@post.comments</tt>. That's a consequence of the declarative associations in the models. Path helpers such as <tt>post_comments_path</tt> come from the nested route declaration in <tt>config/routes.rb</tt>.</p></div>
<divclass="para"><p>Note that each post has its own individual comments collection, accessible as <tt>@post.comments</tt>. That's a consequence of the declarative associations in the models. Path helpers such as <tt>post_comments_path</tt> come from the nested route declaration in <tt>config/routes.rb</tt>.</p></div>
</div>
</div>
<h2id="_what_s_next">8. What's Next?</h2>
<h2id="_what_s_next">9. What's Next?</h2>
<divclass="sectionbody">
<divclass="sectionbody">
<divclass="para"><p>Now that you've seen your first Rails application, you should feel free to update it and experiment on your own. But you don't have to do everything without help. As you need assistance getting up and running with Rails, feel free to consult these support resources:</p></div>
<divclass="para"><p>Now that you've seen your first Rails application, you should feel free to update it and experiment on your own. But you don't have to do everything without help. As you need assistance getting up and running with Rails, feel free to consult these support resources:</p></div>
<divclass="ilist"><ul>
<divclass="ilist"><ul>
...
@@ -1862,7 +2004,7 @@ The <a href="http://wiki.rubyonrails.org/rails">Rails wiki</a>
...
@@ -1862,7 +2004,7 @@ The <a href="http://wiki.rubyonrails.org/rails">Rails wiki</a>
<divclass="para"><p>With most of the options to <tt>render</tt>, the rendered content is displayed as part of the current layout. You'll learn more about layouts and how to use them later in this guide. To find the current layout, Rails first looks for a file in <tt>app/views/layouts</tt> with the same base name as the controller. For example, rendering actions from the <tt>PhotosController</tt> class will use <tt>/app/views/layouts/photos.html.erb</tt>. If there is no such controller-specific layout, Rails will use <tt>/app/views/layouts/application.html.erb</tt>.</p></div>
<divclass="para"><p>With most of the options to <tt>render</tt>, the rendered content is displayed as part of the current layout. You'll learn more about layouts and how to use them later in this guide.</p></div>
<divclass="para"><p>You can use the <tt>:layout</tt> option to tell Rails to use a specific file as the layout for the current action:</p></div>
<divclass="para"><p>You can use the <tt>:layout</tt> option to tell Rails to use a specific file as the layout for the current action:</p></div>
<divclass="listingblock">
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>To find the current layout, Rails first looks for a file in <tt>app/views/layouts</tt> with the same base name as the controller. For example, rendering actions from the <tt>PhotosController</tt> class will use <tt>/app/views/layouts/photos.html.erb</tt>. If there is no such controller-specific layout, Rails will use <tt>/app/views/layouts/application.html.erb</tt>. If there is no <tt>.erb</tt> layout, Rails will use a <tt>.builder</tt> layout if one exists. Rails also provides several ways to more precisely assign specific layouts to individual controllers and actions.</p></div>
<h5id="_specifying_layouts_on_a_per_controller_basis">Specifying Layouts on a per-Controller Basis</h5>
<divclass="para"><p>You can override the automatic layout conventions in your controllers by using the <tt>layout</tt> declaration in the controller. For example:</p></div>
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>With this declaration, all methods within <tt>ProductsController</tt> will use <tt>app/views/layouts/inventory.html.erb</tt> for their layout.</p></div>
<divclass="para"><p>To assign a specific layout for the entire application, use a declaration in your <tt>ApplicationController</tt> class:</p></div>
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>With this declaration, all views in the entire application will use <tt>app/views/layouts/main.html.erb</tt> for their layout.</p></div>
<h5id="_choosing_layouts_at_runtime">Choosing Layouts at Runtime</h5>
<divclass="para"><p>You can use a symbol to defer the choice of layout until a request is processed:</p></div>
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>Now, if the current user is a special user, they'll get a special layout when viewing a product. You can even use an inline method to determine the layout:</p></div>
<divclass="listingblock">
<divclass="content"><!-- Generator: GNU source-highlight 2.9
<divclass="para"><p>Layouts specified at the controller level support <tt>:only</tt> and <tt>:except</tt> options that take either a method name or an array of method names:</p></div>
<divclass="para"><p>With those declarations, the <tt>inventory</tt> layout would be used only for the <tt>index</tt> method, the <tt>product</tt> layout would be used for everything else except the <tt>rss</tt> method, and the <tt>rss</tt> method will have its layout determined by the automatic layout rules.</p></div>
<divclass="para"><p>Sooner or later, most Rails developers will see the error message "Can only render or redirect once per action". While this is annoying, it's relatively easy to fix. Usually it happens because of a fundamental misunderstanding of the way that <tt>render</tt> works.</p></div>
<divclass="para"><p>Sooner or later, most Rails developers will see the error message "Can only render or redirect once per action". While this is annoying, it's relatively easy to fix. Usually it happens because of a fundamental misunderstanding of the way that <tt>render</tt> works.</p></div>
<divclass="para"><p>For example, here's some code that will trigger this error:</p></div>
<divclass="para"><p>For example, here's some code that will trigger this error:</p></div>
<divclass="para"><p>When Rails renders a view as a response, it does so by combining the view with the current layout. To find the current layout, Rails first looks for a file in <tt>app/views/layouts</tt> with the same base name as the controller. For example, rendering actions from the <tt>PhotosController</tt> class will use <tt>/app/views/layouts/photos.html.erb</tt>. If there is no such controller-specific layout, Rails will use <tt>/app/views/layouts/application.html.erb</tt>. You can also specify a particular layout by using the <tt>:layout</tt> option to <tt>render</tt>.</p></div>
<divclass="para"><p>When Rails renders a view as a response, it does so by combining the view with the current layout (using the rules for finding the current layout that were covered earlier in this guide). Within a layout, you have access to three tools for combining different bits of output to form the overall response:</p></div>
<divclass="para"><p>Within a layout, you have access to three tools for combining different bits of output to form the overall response:</p></div>
<divclass="para"><p>This manual describes common security problems in web applications and how to avoid them with Rails. If you have any questions or suggestions, please
<divclass="para"><p>This manual describes common security problems in web applications and how to avoid them with Rails. If you have any questions or suggestions, please
mail me at 42 {<em>et</em>} rorsecurity.info. After reading it, you should be familiar with:</p></div>
mail me, Heiko Webers, at 42 {<em>et</em>} rorsecurity.info. After reading it, you should be familiar with:</p></div>
<divclass="para"><p>This example, again, showed that a blacklist filter is never complete. However, as custom CSS in web applications is a quite rare feature, I am not aware of a whitelist CSS filter. <spanstyle="background-color: #fffcdb;">If you want to allow custom colours or images, you can allow the user to choose them and build the CSS in the web application</span>. Use Rails' <tt>sanitize()</tt> method as a model for a whitelist CSS filter, if you really need one.</p></div>
<divclass="para"><p>This example, again, showed that a blacklist filter is never complete. However, as custom CSS in web applications is a quite rare feature, I am not aware of a whitelist CSS filter. <spanstyle="background-color: #fffcdb;">If you want to allow custom colours or images, you can allow the user to choose them and build the CSS in the web application</span>. Use Rails' <tt>sanitize()</tt> method as a model for a whitelist CSS filter, if you really need one.</p></div>
<divclass="para"><p>—<em>If you want to provide text formatting other than HTML (due to security), use a mark-up language which is converted to HTML on the server-side. <ahref="http://whytheluckystiff.net/ruby/redcloth/">RedCloth</a> is such a language for Ruby, but without precautions, it is also vulnerable to XSS.</em></p></div>
<divclass="para"><p>—<em>If you want to provide text formatting other than HTML (due to security), use a mark-up language which is converted to HTML on the server-side. <ahref="http://whytheluckystiff.net/ruby/redcloth/">RedCloth</a> is such a language for Ruby, but without precautions, it is also vulnerable to XSS.</em></p></div>
<divclass="para"><p>For example, RedCloth translates <em>test</em> to <em>test<em>, which makes the text italic. However, up to the current version 3.0.4, it is still vulnerable to XSS:</p></div>
<divclass="literalblock">
<divclass="content">
<pre><tt>For example, RedCloth translates _test_ to <em>test<em>, which makes the text italic. However, up to the current version 3.0.4, it is still vulnerable to XSS. Get the http://www.redcloth.org[all-new version 4] that removed serious bugs. However, even that version has http://www.rorsecurity.info/journal/2008/10/13/new-redcloth-security.html[some security bugs], so the countermeasures still apply. Here is an example for version 3.0.4:</tt></pre>
<divclass="para"><p>—<em>HTTP headers are dynamically generated and under certain circumstances user input may be injected. This can lead to false redirection, XSS or HTTP response splitting.</em></p></div>
<divclass="para"><p>HTTP request headers have a Referer, User-Agent (client software) and Cookie field, among others. Response headers for example have a status code, Cookie and Location (redirection target URL) field. All of them are user-supplied and may be manipulated with more or less effort. <spanstyle="background-color: #fffcdb;">Remember to escape these header fields, too.</span> For example when you display the user agent in an administration area.</p></div>
<divclass="para"><p>Besides that, it is <spanstyle="background-color: #fffcdb;">important to know what you are doing when building response headers partly based on user input.</span> For example you want to redirect the user back to a specific page. To do that you introduced a “referer“ field in a form to redirect to the given address:</p></div>
<divclass="literalblock">
<divclass="content">
<pre><tt>redirect_to params[:referer]</tt></pre>
</div></div>
<divclass="para"><p>What happens is that Rails puts the string into the Location header field and sends a 302 (redirect) status to the browser. The first thing a malicious user would do, is this:</p></div>
<divclass="para"><p>And due to a bug in (Ruby and) Rails up to version 2.1.2 (excluding it), a hacker may inject arbitrary header fields; for example like this:</p></div>
<divclass="para"><p>Note that "%0d%0a" is URL-encoded for "\r\n" which is a carriage-return and line-feed (CRLF) in Ruby. So the resulting HTTP header for the second example will be the following because the second Location header field overwrites the first.</p></div>
<divclass="literalblock">
<divclass="content">
<pre><tt>HTTP/1.1 302 Moved Temporarily
(...)
Location: http://www.malicious.tld</tt></pre>
</div></div>
<divclass="para"><p>So <spanstyle="background-color: #fffcdb;">attack vectors for Header Injection are based on the injection of CRLF characters in a header field.</span> And what could an attacker do with a false redirection? He could redirect to a phishing site that looks the same as yours, but asks to login again (and sends the login credentials to the attacker). Or he could install malicious software through browser security holes on that site. <spanstyle="background-color: #fffcdb;">Rails 2.1.2 escapes these characters for the Location field in the redirect_to method. Make sure you do it yourself when you build other header fields with user input.</span></p></div>
<divclass="para"><p>If Header Injection was possible, Response Splitting might be, too. In HTTP, the header block is followed by two CRLFs and the actual data (usually HTML). The idea of Response Splitting is to inject two CRLFs into a header field, followed by another response with malicious HTML. The response will be:</p></div>
<divclass="literalblock">
<divclass="content">
<pre><tt>HTTP/1.1 302 Found [First standard 302 response]
Date: Tue, 12 Apr 2005 22:09:07 GMT
Location: Content-Type: text/html
HTTP/1.1 200 OK [Second New response created by attacker begins]
Content-Type: text/html
<html><font color=red>hey</font></html> [Arbitary malicious input is
Keep-Alive: timeout=15, max=100 shown as the redirected page]
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html</tt></pre>
</div></div>
<divclass="para"><p>Under certain circumstances this would present the malicious HTML to the victim. However, this seems to work with Keep-Alive connections, only (and many browsers are using one-time connections). But you can't rely on this. <spanstyle="background-color: #fffcdb;">In any case this is a serious bug, and you should update your Rails to version 2.0.5 or 2.1.2 to eliminate Header Injection (and thus response splitting) risks.</span></p></div>
Active Record association proxies now respect the scope of methods on the proxied object. Previously (given User has_one :account) +@user.account.private_method+ would call the private method on the associated Account object. That fails in Rails 2.2; if you need this functionality, you should use +@user.account.send(:private_method)+ (or make the method public instead of private or protected). Please note that if you're overriding +method_missing+, you should also override +respond_to+ to match the behavior in order for associations to function normally.
Active Record association proxies now respect the scope of methods on the proxied object. Previously (given User has_one :account) +@user.account.private_method+ would call the private method on the associated Account object. That fails in Rails 2.2; if you need this functionality, you should use +@user.account.send(:private_method)+ (or make the method public instead of private or protected). Please note that if you're overriding +method_missing+, you should also override +respond_to+ to match the behavior in order for associations to function normally.
* Lead Contributor: Adam Milligan
* Lead Contributor: Adam Milligan
* More information:
- link:http://afreshcup.com/2008/10/24/rails-22-change-private-methods-on-association-proxies-are-private/[Rails 2.2 Change: Private Methods on Association Proxies are Private]
=== Other ActiveRecord Changes
=== Other ActiveRecord Changes
...
@@ -412,4 +413,4 @@ Previously the above code made available a local variable called +customer+ insi
...
@@ -412,4 +413,4 @@ Previously the above code made available a local variable called +customer+ insi
== Credits
== Credits
Release notes compiled by link:http://afreshcup.com[Mike Gunderloy]
Release notes compiled by link:http://afreshcup.com[Mike Gunderloy]
This guide will explain in detail how the ActiveRecord design pattern is used inside Ruby on Rails to make communication with the database clear and easy to understand.
The intent of this guide is to explain the ActiveRecord implementation used by Rails though easy to understand examples, metaphors and detailed explanations of the actual Rails source code.
Active Record is a design pattern that mitigates the mind-numbing mental gymnastics often needed to get your application to communicate with a database. This guide explains in detail how This guide uses a mix of real-world examples, metaphors and detailed explanations of the actual Rails source code to help you make the most of AcitveRecord.
After reading this guide readers should have a strong grasp of the ActiveRecord concept and how it can be used with or without Rails. Hopefully, some of the philosophical and theoretical intentions discussed here will also make them a stronger and better developer.
== ORM The Blueprint of ActiveRecord
After reading this guide readers should have a strong grasp of the Active Record pattern and how it can be used with or without Rails. Hopefully, some of the philosophical and theoretical intentions discussed here will also make them a stronger and better developer.
If ActiveRecord is the engine of Rails then ORM is the blueprint of that engine. ORM is short for “Object Relational Mapping” and is a programming concept used to make structures within a system relational. ORM seeks to give semantic meaning to the associations between elements of the system for example tables within a database.
As a thought experiment imagine the components that make up a typical car. There are doors, seats, windows, engines etc. Viewed independently they are simple parts, yet when bolted together through the aid of a blueprint, the parts become a more complex device. ORM is the blueprint that describes how the individual parts relate to one another and in some cases infers the part’s purpose through the way the associations are described.
== ORM The Blueprint of Active Record
== ActiveRecord The Engine of Rails
ActiveRecord is a metaphor used to access data within a database. The name “Active Record” was coined by Martin Fowler in his book “Patterns of Enterprise Application Architecture”. ActiveRecord is a conceptual model of the database record and the relationships to other records.
If Active Record is the engine of Rails then ORM is the blueprint of that engine. ORM is short for “Object Relational Mapping” and is a programming concept used to make structures within a system relational. As a thought experiment imagine the components that make up a typical car. There are doors, seats, windows, engines etc. Viewed independently they are simple parts, yet when bolted together through the aid of a blueprint, the parts become a more complex device. ORM is the blueprint that describes how the individual parts relate to one another and in some cases infers the part’s purpose through the way the associations are described.
As a side note, from now when I refer to ActiveRecord I’ll be referring to the specific Rails implementation and not the design pattern in general. I make this distinction because, as Rails has evolved so too has the Rails specific implementation of their version of ActiveRecord.
Specifically, the Rails ActiveRecord pattern adds inheritance and associations. The associations are created by using a DSL (domain specific language) of macros, and a STI (Single Table Inheritance) to facilitate the inheritance.
== Active Record The Engine of Rails
Rails uses ActiveRecord to abstract much of the drudgery or C.R.U.D (explained later) of working with data in databases. Using ActiveRecord Rails automates the mapping between:
Active Record is a design pattern used to access data within a database. The name “Active Record” was coined by Martin Fowler in his book “Patterns of Enterprise Application Architecture”. Essentially, when a record is returned from the database instead of being just the data it is wrapped in a class, which gives you methods to control that data with. The rails framework is built around the MVC (Model View Controller) design patten and the Active Record is used as the default Model.
The Rails community added several useful concepts to their version of Active Record, including inheritance and associations, which are extremely useful for web applications. The associations are created by using a DSL (domain specific language) of macros, and inheritance is achieved through the use of STI (Single Table Inheritance) at the database level.
By following a few simple conventions the Rails Active Record will automatically map between:
* Classes & Database Tables
* Classes & Database Tables
* Class attributes & Database Table Columns
* Class attributes & Database Table Columns
=== Rails Active Record Conventions
Here are the key conventions to consider when using Active Record.
==== Naming Conventions
Database Table - Plural with underscores separating words i.e. (book_clubs)
Model Class - Singular with the first letter of each word capitalized i.e. (BookClub)
Here are some additional Examples:
[grid="all"]
`-------------`---------------
Model / Class Table / Schema
----------------------------
Post posts
LineItem line_items
Deer deer
Mouse mice
Person people
----------------------------
==== Schema Conventions
To take advantage of some of the magic of Rails database tables must be modeled
When these optional fields are used in your database table definition they give the Active Record
instance additional features.
NOTE: While these column names are optional they are in fact reserved by ActiveRecord. Steer clear of reserved keywords unless you want the extra functionality. For example, "type" is a reserved keyword
used to designate a table using Single Table Inheritance. If you are not using STI, try an analogous
keyword like "context", that may still accurately describe the data you are modeling.
By default rails assumes all tables will use “id” as their primary key to identify each record. Though fortunately you won’t have explicitly declare this, Rails will automatically create that field unless you tell it not to.
For example suppose you created a database table called cars:
For example suppose you created a database table called cars:
As you might expect without defining the explicit mappings between your class and the table it is impossible for Rails or any other program to correctly map those relationships.
As you might expect without defining the explicit mappings between your class and the table it is impossible for Rails or any other program to correctly map those relationships.
Now you could define a door methods to write and read data to and from the database. In a nutshell this is what ActiveRecord does. According to the Rails API:
Now you could define a door methods to write and read data to and from the database. In a nutshell this is what ActiveRecord does. According to the Rails API:
“Active Record objects don‘t specify their attributes directly, but rather infer them from the table definition with which they‘re linked. Adding, removing, and changing attributes and their type is done directly in the database. Any change is instantly reflected in the Active Record objects. The mapping that binds a given Active Record class to a certain database table will happen automatically in most common cases, but can be overwritten for the uncommon ones.”
“Active Record objects don‘t specify their attributes directly, but rather infer them from the table definition with which they‘re linked. Adding, removing, and changing attributes and their type is done directly in the database. Any change is instantly reflected in the Active Record objects. The mapping that binds a given Active Record class to a certain database table will happen automatically in most common cases, but can be overwritten for the uncommon ones.”
Lets try our Car class again, this time inheriting from ActiveRecord.
Lets try our Car class again, this time inheriting from ActiveRecord.
This wrapper implements attribute accessors, callbacks and validations, which can make the data more powerful.
Rails further extends this model by giving each ActiveRecord a way of describing the variety of ways records are associated with one another. We will touch on some of these associations later in the guide but I encourage readers who are interested to read the guide to ActiveRecord associations for an in-depth explanation of the variety of ways rails can model associations.
- Associations between objects controlled by meta-programming macros.
== Philosophical Approaches & Common Conventions
Rails has a reputation of being a zero-config framework which means that it aims to get you off the ground with as little pre-flight checking as possible. This speed benefit is achieved by following “Convention over Configuration”, which is to say that if you agree to live with the defaults then you benefit from a the inherent speed-boost. As Courtneay Gasking put it to me once “You don’t want to off-road on Rails”. ActiveRecord is no different, while it’s possible to override or subvert any of the conventions of AR, unless you have a good reason for doing so you will probably be happy with the defaults. The following is a list of the common conventions of ActiveRecord
== ActiveRecord Magic
- timestamps
- updates
== How ActiveRecord Maps your Database.
- sensible defaults
- overriding conventions
== Growing Your Database Relationships Naturally
== Attributes
- attribute accessor method. How to override them?
- attribute?
- dirty records
-
== ActiveRecord handling the CRUD of your Rails application - Understanding the life-cycle of an ActiveRecord
== Validations & Callbacks
- Validations
- Validations
* create!
* create!
* validates_acceptance_of
* validates_acceptance_of
...
@@ -84,37 +178,4 @@ This wrapper implements attribute accessors, callbacks and validations, which ca
...
@@ -84,37 +178,4 @@ This wrapper implements attribute accessors, callbacks and validations, which ca
* (6) before_create
* (6) before_create
* (-) create
* (-) create
* (7) after_create
* (7) after_create
* (8) after_save
* (8) after_save
\ No newline at end of file
Rails further extends this model by giving each ActiveRecord a way of describing the variety of ways records are associated with one another. We will touch on some of these associations later in the guide but I encourage readers who are interested to read the guide to ActiveRecord associations for an in-depth explanation of the variety of ways rails can model associations.
- Associations between objects controlled by meta-programming macros.
== Philosophical Approaches & Common Conventions
Rails has a reputation of being a zero-config framework which means that it aims to get you off the ground with as little pre-flight checking as possible. This speed benefit is achieved by following “Convention over Configuration”, which is to say that if you agree to live with the defaults then you benefit from a the inherent speed-boost. As Courtneay Gasking put it to me once “You don’t want to off-road on Rails”. ActiveRecord is no different, while it’s possible to override or subvert any of the conventions of AR, unless you have a good reason for doing so you will probably be happy with the defaults. The following is a list of the common conventions of ActiveRecord
ActiveRecord is the default model component of the Model-view-controller web-application framework Ruby on Rails, and is also a stand-alone ORM package for other Ruby applications. In both forms, it was conceived of by David Heinemeier Hansson, and has been improved upon by a number of contributors. --wikipedia
- Naming Conventions
- Class Names are Singular
- Tables names are the plural name of the class name
- Tables contain an identity column named id
- ids
== ActiveRecord Magic
- timestamps
- updates
== How ActiveRecord Maps your Database.
- sensible defaults
- overriding conventions
== Growing Your Database Relationships Naturally
== Attributes
- attribute accessor method. How to override them?
- attribute?
- dirty records
-
== ActiveRecord handling the CRUD of your Rails application - Understanding the life-cycle of an ActiveRecord
@@ -107,6 +107,12 @@ For example, to a Rails application a request such as this:
...
@@ -107,6 +107,12 @@ For example, to a Rails application a request such as this:
would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities.
would be understood to refer to a photo resource with the ID of 17, and to indicate a desired action - deleting that resource. REST is a natural style for the architecture of web applications, and Rails makes it even more natural by using conventions to shield you from some of the RESTful complexities.
If you’d like more details on REST as an architectural style, these resources are more approachable than Fielding’s thesis:
* link:http://www.infoq.com/articles/rest-introduction[A Brief Introduction to REST] by Stefan Tilkov
* link:http://bitworking.org/news/373/An-Introduction-to-REST[An Introduction to REST] (video tutorial) by Joe Gregorio
* link:http://en.wikipedia.org/wiki/Representational_State_Transfer[Representational State Transfer] article in Wikipedia
== Creating a New Rails Project
== Creating a New Rails Project
If you follow this guide, you'll create a Rails project called +blog+, a (very) simple weblog. Before you can start building the application, you need to make sure that you have Rails itself installed.
If you follow this guide, you'll create a Rails project called +blog+, a (very) simple weblog. Before you can start building the application, you need to make sure that you have Rails itself installed.
...
@@ -715,7 +721,7 @@ end
...
@@ -715,7 +721,7 @@ end
In the +update+ action, Rails first uses the +:id+ parameter passed back from the edit view to locate the database record that's being edited. The +update_attributes+ call then takes the rest of the parameters from the request and applies them to this record. If all goes well, the user is redirected to the post's +show+ view. If there are any problems, it's back to +edit+ to correct them.
In the +update+ action, Rails first uses the +:id+ parameter passed back from the edit view to locate the database record that's being edited. The +update_attributes+ call then takes the rest of the parameters from the request and applies them to this record. If all goes well, the user is redirected to the post's +show+ view. If there are any problems, it's back to +edit+ to correct them.
NOTE: Sharp-eyed readers will have noticed that the +form_for+ declaration is identical for the +create+ and +edit+ views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a _partial template_, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that’s easy to modify if you want different forms for +create+ and +edit+.
NOTE: Sharp-eyed readers will have noticed that the +form_for+ declaration is identical for the +new+ and +edit+ views. Rails generates different code for the two forms because it's smart enough to notice that in the one case it's being passed a new record that has never been saved, and in the other case an existing record that has already been saved to the database. In a production Rails application, you would ordinarily eliminate this duplication by moving identical code to a _partial template_, which you could then include in both parent templates. But the scaffold generator tries not to make too many assumptions, and generates code that’s easy to modify if you want different forms for +create+ and +edit+.
=== Destroying a Post
=== Destroying a Post
...
@@ -736,6 +742,125 @@ end
...
@@ -736,6 +742,125 @@ end
The +destroy+ method of an Active Record model instance removes the corresponding record from the database. After that's done, there isn't any record to display, so Rails redirects the user's browser to the index view for the model.
The +destroy+ method of an Active Record model instance removes the corresponding record from the database. After that's done, there isn't any record to display, so Rails redirects the user's browser to the index view for the model.
== DRYing up the Code
At this point, it’s worth looking at some of the tools that Rails provides to eliminate duplication in your code. In particular, you can use _partials_ to clean up duplication in views and _filters_ to help with duplication in controllers.
=== Using Partials to Eliminate View Duplication
As you saw earlier, the scaffold-generated views for the +new+ and +edit+ actions are largely identical. You can pull the shared code out into a +partial+ template. This requires editing the new and edit views, and adding a new template:
Now, when Rails renders the +new+ or +edit+ view, it will insert the +_form+ partial at the indicated point. Note the naming convention for partials: if you refer to a partial named +form+ inside of a view, the corresponding file is +_form.html.erb+, with a leading underscore.
For more information on partials, refer to the link:../layouts_and_rendering.html[Layouts and Rending in Rails] guide.
=== Using Filters to Eliminate Controller Duplication
At this point, if you look at the controller for posts, you’ll see some duplication:
Four instances of the exact same line of code doesn’t seem very DRY. Rails provides _filters_ as a way to address this sort of repeated code. In this case, you can DRY things up by using a +before_filter+:
Rails runs _before filters_ before any action in the controller. You can use the +:only+ clause to limit a before filter to only certain actions, or an +:except+ clause to specifically skip a before filter for certain actions. Rails also allows you to define _after filters_ that run after processing an action, as well as _around filters_ that surround the processing of actions. Filters can also be defined in external classes to make it easy to share them between controllers.
For more information on filters, see the link:actioncontroller_basics.html[Action Controller Basics] guide.
== Adding a Second Model
== Adding a Second Model
Now that you've seen what's in a model built with scaffolding, it's time to add a second model to the application. The second model will handle comments on blog posts.
Now that you've seen what's in a model built with scaffolding, it's time to add a second model to the application. The second model will handle comments on blog posts.
...
@@ -798,7 +923,7 @@ Rails is smart enough to only execute the migrations that have not already been
...
@@ -798,7 +923,7 @@ Rails is smart enough to only execute the migrations that have not already been
=== Associating Models
=== Associating Models
Active Record associations let you declaratively quantify the relationship between two models. In the case of comments and posts, you could write out the relationships this way:
Active Record associations let you easily declare the relationship between two models. In the case of comments and posts, you could write out the relationships this way:
* Each comment belongs to one post
* Each comment belongs to one post
* One post can have many comments
* One post can have many comments
...
@@ -825,7 +950,7 @@ end
...
@@ -825,7 +950,7 @@ end
These two declarations enable a good bit of automatic behavior. For example, if you have an instance variable +@post+ containing a post, you can retrieve all the comments belonging to that post as the array +@post.comments+.
These two declarations enable a good bit of automatic behavior. For example, if you have an instance variable +@post+ containing a post, you can retrieve all the comments belonging to that post as the array +@post.comments+.
TIP: For more information on Active Record associations, see the link:../association_basics.html+[Active Record Associations] guide.
TIP: For more information on Active Record associations, see the link:../association_basics.html[Active Record Associations] guide.
With most of the options to +render+, the rendered content is displayed as part of the current layout. You'll learn more about layouts and how to use them later in this guide. To find the current layout, Rails first looks for a file in +app/views/layouts+ with the same base name as the controller. For example, rendering actions from the +PhotosController+ class will use +/app/views/layouts/photos.html.erb+. If there is no such controller-specific layout, Rails will use +/app/views/layouts/application.html.erb+.
With most of the options to +render+, the rendered content is displayed as part of the current layout. You'll learn more about layouts and how to use them later in this guide.
You can use the +:layout+ option to tell Rails to use a specific file as the layout for the current action:
You can use the +:layout+ option to tell Rails to use a specific file as the layout for the current action:
...
@@ -223,6 +223,124 @@ You can use the +:location+ option to set the HTTP +Location+ header:
...
@@ -223,6 +223,124 @@ You can use the +:location+ option to set the HTTP +Location+ header:
To find the current layout, Rails first looks for a file in +app/views/layouts+ with the same base name as the controller. For example, rendering actions from the +PhotosController+ class will use +/app/views/layouts/photos.html.erb+. If there is no such controller-specific layout, Rails will use +/app/views/layouts/application.html.erb+. If there is no +.erb+ layout, Rails will use a +.builder+ layout if one exists. Rails also provides several ways to more precisely assign specific layouts to individual controllers and actions.
===== Specifying Layouts on a per-Controller Basis
You can override the automatic layout conventions in your controllers by using the +layout+ declaration in the controller. For example:
Now, if the current user is a special user, they'll get a special layout when viewing a product. You can even use an inline method to determine the layout:
With those declarations, the +inventory+ layout would be used only for the +index+ method, the +product+ layout would be used for everything else except the +rss+ method, and the +rss+ method will have its layout determined by the automatic layout rules.
===== Layout Inheritance
Layouts are shared downwards in the hierarchy, and more specific layouts always override more general ones. For example:
* In general, views will be rendered in the +main+ layout
* +PostsController#index+ will use the +main+ layout
* +SpecialPostsController#index+ will use the +special+ layout
* +OldPostsController#show+ will use no layout at all
* +OldPostsController#index+ will use the +old+ layout
==== Avoiding Double Render Errors
==== Avoiding Double Render Errors
Sooner or later, most Rails developers will see the error message "Can only render or redirect once per action". While this is annoying, it's relatively easy to fix. Usually it happens because of a fundamental misunderstanding of the way that +render+ works.
Sooner or later, most Rails developers will see the error message "Can only render or redirect once per action". While this is annoying, it's relatively easy to fix. Usually it happens because of a fundamental misunderstanding of the way that +render+ works.
...
@@ -332,9 +450,7 @@ head :created, :location => photo_path(@photo)
...
@@ -332,9 +450,7 @@ head :created, :location => photo_path(@photo)
== Structuring Layouts
== Structuring Layouts
When Rails renders a view as a response, it does so by combining the view with the current layout. To find the current layout, Rails first looks for a file in +app/views/layouts+ with the same base name as the controller. For example, rendering actions from the +PhotosController+ class will use +/app/views/layouts/photos.html.erb+. If there is no such controller-specific layout, Rails will use +/app/views/layouts/application.html.erb+. You can also specify a particular layout by using the +:layout+ option to +render+.
When Rails renders a view as a response, it does so by combining the view with the current layout (using the rules for finding the current layout that were covered earlier in this guide). Within a layout, you have access to three tools for combining different bits of output to form the overall response:
Within a layout, you have access to three tools for combining different bits of output to form the overall response:
This manual describes common security problems in web applications and how to avoid them with Rails. If you have any questions or suggestions, please
This manual describes common security problems in web applications and how to avoid them with Rails. If you have any questions or suggestions, please
mail me at 42 {_et_} rorsecurity.info. After reading it, you should be familiar with:
mail me, Heiko Webers, at 42 {_et_} rorsecurity.info. After reading it, you should be familiar with:
- All countermeasures [,#fffcdb]#that are highlighted#
- All countermeasures [,#fffcdb]#that are highlighted#
- The concept of sessions in Rails, what to put in there and popular attack methods
- The concept of sessions in Rails, what to put in there and popular attack methods
...
@@ -858,7 +858,8 @@ This example, again, showed that a blacklist filter is never complete. However,
...
@@ -858,7 +858,8 @@ This example, again, showed that a blacklist filter is never complete. However,
-- _If you want to provide text formatting other than HTML (due to security), use a mark-up language which is converted to HTML on the server-side. http://whytheluckystiff.net/ruby/redcloth/[RedCloth] is such a language for Ruby, but without precautions, it is also vulnerable to XSS._
-- _If you want to provide text formatting other than HTML (due to security), use a mark-up language which is converted to HTML on the server-side. http://whytheluckystiff.net/ruby/redcloth/[RedCloth] is such a language for Ruby, but without precautions, it is also vulnerable to XSS._
For example, RedCloth translates _test_ to <em>test<em>, which makes the text italic. However, up to the current version 3.0.4, it is still vulnerable to XSS:
For example, RedCloth translates _test_ to <em>test<em>, which makes the text italic. However, up to the current version 3.0.4, it is still vulnerable to XSS. Get the http://www.redcloth.org[all-new version 4] that removed serious bugs. However, even that version has http://www.rorsecurity.info/journal/2008/10/13/new-redcloth-security.html[some security bugs], so the countermeasures still apply. Here is an example for version 3.0.4:
-- _HTTP headers are dynamically generated and under certain circumstances user input may be injected. This can lead to false redirection, XSS or HTTP response splitting._
HTTP request headers have a Referer, User-Agent (client software) and Cookie field, among others. Response headers for example have a status code, Cookie and Location (redirection target URL) field. All of them are user-supplied and may be manipulated with more or less effort. [,#fffcdb]#Remember to escape these header fields, too.# For example when you display the user agent in an administration area.
Besides that, it is [,#fffcdb]#important to know what you are doing when building response headers partly based on user input.# For example you want to redirect the user back to a specific page. To do that you introduced a “referer“ field in a form to redirect to the given address:
..........
redirect_to params[:referer]
..........
What happens is that Rails puts the string into the Location header field and sends a 302 (redirect) status to the browser. The first thing a malicious user would do, is this:
Note that "%0d%0a" is URL-encoded for "\r\n" which is a carriage-return and line-feed (CRLF) in Ruby. So the resulting HTTP header for the second example will be the following because the second Location header field overwrites the first.
..........
HTTP/1.1 302 Moved Temporarily
(...)
Location: http://www.malicious.tld
..........
So [,#fffcdb]#attack vectors for Header Injection are based on the injection of CRLF characters in a header field.# And what could an attacker do with a false redirection? He could redirect to a phishing site that looks the same as yours, but asks to login again (and sends the login credentials to the attacker). Or he could install malicious software through browser security holes on that site. [,#fffcdb]#Rails 2.1.2 escapes these characters for the Location field in the redirect_to method. Make sure you do it yourself when you build other header fields with user input.#
==== Response Splitting
If Header Injection was possible, Response Splitting might be, too. In HTTP, the header block is followed by two CRLFs and the actual data (usually HTML). The idea of Response Splitting is to inject two CRLFs into a header field, followed by another response with malicious HTML. The response will be:
..........
HTTP/1.1 302 Found [First standard 302 response]
Date: Tue, 12 Apr 2005 22:09:07 GMT
Location: Content-Type: text/html
HTTP/1.1 200 OK [Second New response created by attacker begins]
Content-Type: text/html
<html><font color=red>hey</font></html> [Arbitary malicious input is
Keep-Alive: timeout=15, max=100 shown as the redirected page]
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
..........
Under certain circumstances this would present the malicious HTML to the victim. However, this seems to work with Keep-Alive connections, only (and many browsers are using one-time connections). But you can't rely on this. [,#fffcdb]#In any case this is a serious bug, and you should update your Rails to version 2.0.5 or 2.1.2 to eliminate Header Injection (and thus response splitting) risks.#
== Additional resources
== Additional resources
The security landscape shifts and it is important to keep up to date, because missing a new vulnerability can be catastrophic. You can find additional resources about (Rails) security here:
The security landscape shifts and it is important to keep up to date, because missing a new vulnerability can be catastrophic. You can find additional resources about (Rails) security here: