Backblaze
Fixed cache when using application keys
Fixed authorize_account to compare the application_key_id parameter to the old application_key_id instead of the account_id. This used to result in the cache being cleared on every call to authorize_account, unless the master application key for the account was in use.
I don't think this fix is correct.
b2_authorize_account returns the account_id and we should compare it to the one that we had already in account_info. If those are the same, then either:
- the current key and the old key were the same
- the current key is from the same account as the old key and maybe we don't need to clear the cache, at least not entire cache, because the new key can be restricted to just one bucket and in such case it is questionable whether cache of the other buckets from the same account should be cleared or kept.
If the account ids are different, then the user wants to switch accounts and clearing the cache in such case is a good idea (probably. I am wondering now why are we clearing this cache at all, is the cache really sensitive?)
The problem is that currently, application_key_id is checked against the old account_id. That seems to be comparing apples to oranges. My fix was to check the given application_key_id against the old application_key_id. That seemed like the more sane comparison to make.
Yes, it is making things a little bit better, but is that a correct fix?
@bwbeach should bucket name-to-id cache entries be considered sensitive for the users of the same account (but different keys possibly restricted to different buckets)?
My opinion is that it's reasonable to assume that the user of the account is the "same person" for the purposes of hiding information. If you're in the same account, you can see shell history, browser history, etc. I don't think there's any expectation of privacy.
Ok @phistrom I think the correct fix is to not clear the cache before calling self.raw_api.authorize_account(). After we call it, we'll get a new account_id, which we can compare with the account_id currently in the database and THEN if those two are different, we should clear the cache. This will let us change from a master key to a bucket key of the same account without clearing the cache (and back). Does it make sense?
Ok, will you do the honors? Also please update the changelog and maybe add a test case, the behavior which you have encountered and the one that we have just discussed should probably be preserved in the future, so a little bit of regression testing would not hurt!
Seems this code has been since entirely replaced; Thank you for brining it to our attention at that time nevertheless.
