3 ms·

Why is anyone putting anything in a cookie besides a [protected] session ID? I can store your account details (the ID my store uses to identify you, your first

by delinka 14y ago

Why is anyone putting anything in a cookie besides a [protected] session ID? I can store your account details (the ID my store uses to identify you, your first name for dispaly on pages) in the session object on the server and access them when my store page scripts need them. Why does anyone need any of this in a cookie? I don't get it... It's a fundamental property of user-facing apps that you can't trust anything provided by a user (or anything that can impersonate a user.) Got some input that you're gonna store in the database? Use the database sanitizing functions to clean it up before putting it in the database. Going to display some of that back to the user? Pull it out of the database and HTML encode it before putting it in the page. Is it just blind trust in users that keeps web dev people doing this? Or is it truly lack of comprehension? Either way it's incompetence.

tedunangst 14y ago
It appears to be how things are done in a number of frameworks. In a bizarre parallel to mgkimsal's comment, whenever I've asked about it, I've been told I just don't get web programming. To my mind, the term cookie implies some sort of opaque handle. I give it to you, you give it back to me. It doesn't contain data, it's just a handle. A base64 encoded 128-bit number also solves the problem of "omg, our cookies are so long we need a separate domain for static assets to reduce our bandwidth".
- pmahoney 14y ago
  Rails claims its CookieStore will "greatly increase the speed of the application" relative to other stores (the guide mentions a file store and a database store) [1]. The cookie is a base64 encoded hash serialization (i.e. completely reversible by the client), but "to prevent session hash tampering, a digest is calculated from the session with a server-side secret and inserted into the end of the cookie." I've not seen or performed myself any measurements of these claims. I have seen it suggested that CookieStore is the default because it is simpler in not requiring a database table, and not for any performance benefit. Without measuring, I can only guess the difference is dwarfed by the typical page load time. [1] http://guides.rubyonrails.org/security.html#session-storage http://guides.rubyonrails.org/security.html#session-storage

by delinka 14y ago

tedunangst 14y ago

It appears to be how things are done in a number of frameworks. In a bizarre parallel to mgkimsal's comment, whenever I've asked about it, I've been told I just don't get web programming. To my mind, the term cookie implies some sort of opaque handle. I give it to you, you give it back to me. It doesn't contain data, it's just a handle. A base64 encoded 128-bit number also solves the problem of "omg, our cookies are so long we need a separate domain for static assets to reduce our bandwidth".

pmahoney 14y ago
Rails claims its CookieStore will "greatly increase the speed of the application" relative to other stores (the guide mentions a file store and a database store) [1]. The cookie is a base64 encoded hash serialization (i.e. completely reversible by the client), but "to prevent session hash tampering, a digest is calculated from the session with a server-side secret and inserted into the end of the cookie." I've not seen or performed myself any measurements of these claims. I have seen it suggested that CookieStore is the default because it is simpler in not requiring a database table, and not for any performance benefit. Without measuring, I can only guess the difference is dwarfed by the typical page load time. [1] http://guides.rubyonrails.org/security.html#session-storage http://guides.rubyonrails.org/security.html#session-storage