Upcoming policy: Use IdentityManager instead of SigninManager and ProfileOAuth2TokenService
Colin Blundell
TL;DR
On ~December 18, we will be introducing DEPS restrictions preventing new includes of SigninManager and ProfileOAuth2TokenService. Instead, you should use IdentityManager. Contact identity-s...@chromium.org if you encounter any problems while doing so; exceptions are possible if necessary.
Hello all,
We are in the process of converting Chromium away from using its existing APIs for interacting with the user’s Gaia identities to a next-generation API, IdentityManager. In the first phase, we have been focusing on conversion of SigninManager and ProfileOAuth2TokenService. We are now ready to disallow new usage of these classes; new code should instead use IdentityManager to fulfill these purposes.
FAQ:
When will the new policy be enforced? Starting ~December 18, assuming no blocking objections are raised this week.
How do I work with IdentityManager? The migration doc is here.
What if I don’t see how to achieve my use case? While we believe that we have support for the vast majority of common use cases, there are some esoteric use cases for which we are still adding support. If you believe that your use case is not supported, reach out to identity-s...@chromium.org. We will rapidly either (1) build out support for your use case, or (2) give you an exception.
How are you forbidding new includes? Via DEPS rules that admit exceptions for all the existing includes (which we will be burning down, of course).
Will you be adding more API surfaces to the forbidden set? Yes! Over the upcoming months, all the files in this target will be added. We will send out updates when adding new files to the “forbidden set.”
Halp?! Contact identity-s...@chromium.org with any questions.