From dadfa1e34f3ffbc2de98eae88b9715c41f4a1b66 Mon Sep 17 00:00:00 2001
From: PoTe <poteland@gmail.com>
Date: Thu, 13 Oct 2011 22:31:32 -0200
Subject: security reasonS should be plural

---
 railties/guides/source/action_controller_overview.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/action_controller_overview.textile')

diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index d8d66302fe..5019d49686 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -796,7 +796,7 @@ NOTE: Certain exceptions are only rescuable from the +ApplicationController+ cla
 
 h3. Force HTTPS protocol
 
-Sometime you might want to force a particular controller to only be accessible via an HTTPS protocol for security reason. Since Rails 3.1 you can now use +force_ssl+ method in your controller to enforce that:
+Sometime you might want to force a particular controller to only be accessible via an HTTPS protocol for security reasons. Since Rails 3.1 you can now use +force_ssl+ method in your controller to enforce that:
 
 <ruby>
 class DinnerController
-- 
cgit v1.2.3


From 2b04c2f66e3cf5abbbf118eaa1e692b9e1380e4e Mon Sep 17 00:00:00 2001
From: Brian Durand <brian@embellishedvisions.com>
Date: Fri, 21 Oct 2011 13:13:29 -0500
Subject: Add ActionDispatch::Session::CacheStore as a generic way of storing
 sessions in a cache.

---
 railties/guides/source/action_controller_overview.textile | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

(limited to 'railties/guides/source/action_controller_overview.textile')

diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index 5019d49686..b34c223b31 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -166,10 +166,10 @@ h3. Session
 
 Your application has a session for each user in which you can store small amounts of data that will be persisted between requests. The session is only available in the controller and the view and can use one of a number of different storage mechanisms:
 
-* CookieStore - Stores everything on the client.
-* DRbStore - Stores the data on a DRb server.
-* MemCacheStore - Stores the data in a memcache.
-* ActiveRecordStore - Stores the data in a database using Active Record.
+* ActionDispatch::Session::CookieStore - Stores everything on the client.
+* ActiveRecord::SessionStore - Stores the data in a database using Active Record.
+* ActionDispatch::Session::CacheStore - Stores the data in the Rails cache.
+* ActionDispatch::Session::MemCacheStore - Stores the data in a memcached cluster (this is a legacy implementation; consider using CacheStore instead).
 
 All session stores use a cookie to store a unique ID for each session (you must use a cookie, Rails will not allow you to pass the session ID in the URL as this is less secure).
 
@@ -177,6 +177,8 @@ For most stores this ID is used to look up the session data on the server, e.g.
 
 The CookieStore can store around 4kB of data -- much less than the others -- but this is usually enough. Storing large amounts of data in the session is discouraged no matter which session store your application uses. You should especially avoid storing complex objects (anything other than basic Ruby objects, the most common example being model instances) in the session, as the server might not be able to reassemble them between requests, which will result in an error.
 
+If your user sessions don't store critical data or don't need to be around for long periods (for instance if you just use the flash for messaging), you can consider using ActionDispatch::Session::CacheStore. This will store sessions using the cache implementation you have configured for your application. The advantage of this is that you can use your existing cache infrastructure for storing sessions without requiring any additional setup or administration. The downside, of course, is that the sessions will be ephemeral and could disappear at any time.
+
 Read more about session storage in the "Security Guide":security.html.
 
 If you need a different session storage mechanism, you can change it in the +config/initializers/session_store.rb+ file:
-- 
cgit v1.2.3


From 8a67b632ae320e1983d8170f9c348c5a6333c9af Mon Sep 17 00:00:00 2001
From: sandeepravi <sandeep.ravichandran@sourcebits.com>
Date: Tue, 6 Dec 2011 17:22:48 +0530
Subject: Added wiki link for REST

---
 railties/guides/source/action_controller_overview.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/action_controller_overview.textile')

diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index b34c223b31..a55b7ba762 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -16,7 +16,7 @@ h3. What Does a Controller Do?
 
 Action Controller is the C in MVC. After routing has determined which controller to use for a request, your controller is responsible for making sense of the request and producing the appropriate output. Luckily, Action Controller does most of the groundwork for you and uses smart conventions to make this as straightforward as possible.
 
-For most conventional RESTful applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
+For most conventional {REST}[http://en.wikipedia.org/wiki/Representational_state_transfer]ful applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
 
 A controller can thus be thought of as a middle man between models and views. It makes the model data available to the view so it can display that data to the user, and it saves or updates data from the user to the model.
 
-- 
cgit v1.2.3


From bc994470c49fb17a6f984513c1299b94616ab83f Mon Sep 17 00:00:00 2001
From: sandeepravi <sandeep.ravichandran@sourcebits.com>
Date: Tue, 6 Dec 2011 17:50:16 +0530
Subject: Added wiki link to REST

---
 railties/guides/source/action_controller_overview.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/action_controller_overview.textile')

diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index a55b7ba762..965da9f7dc 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -16,7 +16,7 @@ h3. What Does a Controller Do?
 
 Action Controller is the C in MVC. After routing has determined which controller to use for a request, your controller is responsible for making sense of the request and producing the appropriate output. Luckily, Action Controller does most of the groundwork for you and uses smart conventions to make this as straightforward as possible.
 
-For most conventional {REST}[http://en.wikipedia.org/wiki/Representational_state_transfer]ful applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
+For most conventional <span><a href="http://en.wikipedia.org/wiki/Representational_state_transfer">REST</a>ful</span> applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
 
 A controller can thus be thought of as a middle man between models and views. It makes the model data available to the view so it can display that data to the user, and it saves or updates data from the user to the model.
 
-- 
cgit v1.2.3


From 078b4b54a6ce655854bae5f9f931423410d46ff8 Mon Sep 17 00:00:00 2001
From: Vijay Dev <vijaydev.cse@gmail.com>
Date: Tue, 6 Dec 2011 22:51:07 +0530
Subject: use textile syntax in links

---
 railties/guides/source/action_controller_overview.textile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'railties/guides/source/action_controller_overview.textile')

diff --git a/railties/guides/source/action_controller_overview.textile b/railties/guides/source/action_controller_overview.textile
index 965da9f7dc..bc85f07ecc 100644
--- a/railties/guides/source/action_controller_overview.textile
+++ b/railties/guides/source/action_controller_overview.textile
@@ -16,7 +16,7 @@ h3. What Does a Controller Do?
 
 Action Controller is the C in MVC. After routing has determined which controller to use for a request, your controller is responsible for making sense of the request and producing the appropriate output. Luckily, Action Controller does most of the groundwork for you and uses smart conventions to make this as straightforward as possible.
 
-For most conventional <span><a href="http://en.wikipedia.org/wiki/Representational_state_transfer">REST</a>ful</span> applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
+For most conventional "RESTful":http://en.wikipedia.org/wiki/Representational_state_transfer applications, the controller will receive the request (this is invisible to you as the developer), fetch or save data from a model and use a view to create HTML output. If your controller needs to do things a little differently, that's not a problem, this is just the most common way for a controller to work.
 
 A controller can thus be thought of as a middle man between models and views. It makes the model data available to the view so it can display that data to the user, and it saves or updates data from the user to the model.
 
-- 
cgit v1.2.3

