This is hardly a flaw in Rails - if the user's login session isn't ended before handing physical access to another person, that's not really the software's problem.
I didn't say it is a flaw. IMHO the default caching setting is how it should be, but the developer should be aware of the http caching, and should turn it off where it can lead to information leaking.
Putting the database row ID in urls, which is the Rails default, basically lets a competitor plot your growth with a simple script.
Which is only a 'problem' (we'll assume there's 1:1 between DB rows and growth) with incrementing column IDs. UUIDv4's or some other random ID (24-bit base64, composite IDs with a shard prefix, etc) don't have this problem.
Comments
This is hardly a flaw in Rails - if the user's login session isn't ended before handing physical access to another person, that's not really the software's problem.
I didn't say it is a flaw. IMHO the default caching setting is how it should be, but the developer should be aware of the http caching, and should turn it off where it can lead to information leaking.
Hm, I thought it was going to be talking about leaking information from your app, not browser cache.
Putting the database row ID in urls, which is the Rails default, basically lets a competitor plot your growth with a simple script.
Which is only a 'problem' (we'll assume there's 1:1 between DB rows and growth) with incrementing column IDs. UUIDv4's or some other random ID (24-bit base64, composite IDs with a shard prefix, etc) don't have this problem.
or slugs.