The
session store is usually a server-side data store tied to a unique session identifier in a
cookie. Because session IDs are sparse and hard to guess, it is a safe assumption that
if a user presents a particular session ID, he has access to that session. And since the
application code is the only thing that can access the session store, you can trust that
the data you read is the same as what you wrote.
There is a new method of session storage, CookieStore, that is now the default in
edge Rails and Rails 2.0. It marshals the entire session into a cookie, rather than keying
a server-side session from a client-side cookie. The idea is that most sessions are
small, usually containing only a user ID and flash message. Cookies work fine for
this (they usually have a 4 KB limit). Rails ensures data integrity by signing the
cookie with a message authentication code (MAC) and raising a TamperedWithCookie
exception if the data was modified.
Double-check everything
Here is another mistake that is easy to make in Rails. Because the REST philosophy
behind Rails encourages resource-based URIs (each URI represents a particular
resource or object), it can be easy to overlook security. This happens often when
finding a record from the database by primary key??”often it is easy to neglect checking
for proper ownership. Here is an example that illustrates that problem:
app/models/message.
Pages:
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209