This
can get tricky and is often inefficient. Database-backed sessions solve this problem
by keeping session state in a central database. However, this database can become a
bottleneck because it must be accessed once for every request that needs session data
(such as for user authentication). The DRb session store is not widely used and
requires running yet another server process.
There is a solution to these problems. Most Rails sessions are lightweight: they usually
contain little more than a user ID (if authenticated) and possibly a flash message.
This means that they can be stored on the client rather than the server. The
Rails CookieStore does just this: instead of storing the session on the server and storing
its ID on the client in a cookie, it stores the entire session in a cookie.
Of course, security must be taken into account. Remember the all-important rule:
never trust the client. If we just marshaled data into a string and placed it in a cookie,
we would have no way to prevent the client from tampering with the session. The
user could simply send the cookie corresponding to the session data user_id=1 and
trick the server into thinking that he was logged in as the user with ID 1.
To counter this, the CookieStore signs each cookie with an HMAC (keyed-hash message
authentication code), which is essentially a hash of the cookie data along with a
secret key.
Pages:
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216