aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source/action_controller_overview.md
diff options
context:
space:
mode:
authorHarshad Sabne <harshadsabne@users.noreply.github.com>2013-11-15 22:32:44 +0530
committerHarshad Sabne <harshadsabne@users.noreply.github.com>2013-11-15 22:32:44 +0530
commit4a98938ff4de038e003ec091e5e663876e4f3817 (patch)
tree21d35109a4c7245d06d8eb92688a06912d6fd0bc /guides/source/action_controller_overview.md
parentdeeeaef6d2f49edb4eda0cfbab7f585a3eb520be (diff)
downloadrails-4a98938ff4de038e003ec091e5e663876e4f3817.tar.gz
rails-4a98938ff4de038e003ec091e5e663876e4f3817.tar.bz2
rails-4a98938ff4de038e003ec091e5e663876e4f3817.zip
Update action_controller_overview.md [ci skip]
Code style adherence
Diffstat (limited to 'guides/source/action_controller_overview.md')
-rw-r--r--guides/source/action_controller_overview.md2
1 files changed, 1 insertions, 1 deletions
diff --git a/guides/source/action_controller_overview.md b/guides/source/action_controller_overview.md
index cd4a1a0792..5bea8ff3a3 100644
--- a/guides/source/action_controller_overview.md
+++ b/guides/source/action_controller_overview.md
@@ -350,7 +350,7 @@ 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.
+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).