3 ms·
I dunno, I guess the same could be said about your database then, no? If you're doing: SELECT * FROM serious_money_table WHERE user_id = :user_id; How is
by 3pt14159 4y ago
I dunno, I guess the same could be said about your database then, no?
If you're doing:
SELECT * FROM serious_money_table WHERE user_id = :user_id;
How is it all that different with Redis? Someone can mistakenly send in a :customer_id when writing records, but I don't really know anyone out there that also stores user_id into every table they query user_id from.
- spullara 4y agoIf you are querying for user_id by definition the table contains user_id. I think what they are suggesting is checking that the data returned from the query has the correct user_id. No one would do that because if you can't trust your database to answer queries correctly you have more problems than just that. My guess with the Royal Mail is that it is probably something dumb like using a field in (Java) servlet to hold the data which is then shared across all sessions. I have seen that multiple times in my career. People don't notice when testing as there is only one session at a time.
- contravariant 4y agoI'll be honest I don't have much experience with Redis specifically, I do however think that the caching layer is likely the wrong place to handle data security. It seems too easy for someone to accidentally circumvent the cache and thereby the security. I do think that organising the cache to catch problems early is a good idea though. The thing is that a function like def get_profile(user_id): profile = fetch_profile(user_id) assert profile.user_id == user_id return user_id makes it a lot harder to fuck up, doesn't matter if you swap some ids somewhere (i.e. fetch_profile actually uses the customer id, not the user_id), or if the cache fucks up, or if you accidentally wrote 'SELECT * FROM user_profile WHERE user_id = user_id'.