IdentityManager: Add APIs for querying state of refresh tokens
This CL adds APIs to IdentityManager for obtaining the set of all accounts with refresh tokens and querying whether the primary account is available with a refresh token. The design follows that of IdentityManager's caching of the primary account information: - IdentityManager initializes its state with the current state of ProfileOAuth2TokenService. - IdentityManager updates this state in response to notifications from PO2TS that an account's refresh token was updated/removed. This CL is a reland of https://chromium-review.googlesource.com/c/chromium/src/+/1098668 with the following addition: In https://chromium-review.googlesource.com/c/chromium/src/+/1098668, we made the assumption that when IdentityManager receives a notification from ProfileOAuth2TokenService that a token will be revoked, it had previously known about that account (either because the account was available at IdentityManager startup or because IdentityManager previously received a notification from PO2TS that a refresh token had been made available for the account). However, as demonstrated in the linked bug, it turns out that this assumption is not valid in one case: while loading tokens during startup, PO2TS sometimes revokes tokens without having previously made them available. This violation of IdentityManager's assumption causes a crash. It is not feasible at the current time to change this behavior on the part of PO2TS, as AccountTrackerService should be made aware of these events so that it removes the accounts. However, this situation poses a challenge for IdentityManager: Should it forward on the callback to its own observers or not? In this CL, we fix the crash and additionally nail down the semantics that IdentityManager sends token removed callbacks only for accounts of which it previously knew the existence. The reasons for making this choice on the semantics are twofold: (1) Sending an observer callback that a token was removed for an account that was not previously present in IdentityManager::GetAccountsWithRefreshTokens() seems like a violation of the principle of least surprise. (2) It's not clear that AccountTrackerService will always know about the account in this case, in which case we wouldn't have the full information to forward on in the observer callback. This does mean that IdentityManager::Observer::OnRefreshTokenRemovedForAccount() is not strictly identical semantically to ProfileOAuth2TokenService::Observer::OnRefreshTokenRevoked(). However, we strongly believe that the only consumer that needs to know about revocations in this corner case is AccountTrackerService, which will not be converted to depend on IdentityManager as it lives below IdentityManager. TBR=bsazonov@chromium.org Bug: 806774 Change-Id: I9f77525e26825ab418b15c7d1c2a8e4f8e3b4910 Reviewed-on: https://chromium-review.googlesource.com/1124320 Commit-Queue: Colin Blundell <blundell@chromium.org> Reviewed-by:Mihai Sardarescu <msarda@chromium.org> Cr-Commit-Position: refs/heads/master@{#572185}
Showing
This diff is collapsed.
Please register or sign in to comment