Expand description
OAuth2 authentication: PKCE loopback flow (RFC 8252) with an RFC 8628 device-flow fallback, tokens in the OS keyring.
Multi-account: one OAuth client, one token per Google account. An auth handle is bound to one account’s store entry (the default account keeps the legacy naming byte-for-byte); named accounts log in independently.
Structs§
- Device
Auth Challenge - Pending device authorization: show
verification_url+user_codeto the user, then poll withsuper::GoogleAuth::poll_device_codeuntil done. - Google
Auth - OAuth2 client with PKCE support
- Token
Storage - Token storage with automatic refresh.
Functions§
- login_
scopes - [
LOGIN_SCOPES], filtered to scopes the embedded index actually declares — requesting one no build can declare is a consent hang of its own. - scopes
- Every scope the embedded index names, minus the ones Google will not show
a user (see [
APP_AUTH_SCOPES]), plus a curated floor for scopes no method declares. This is the superset a credential may hold — whatgrr auth login --all-scopesasks for, and whatgrr api describecounts against — but deliberately not what a login requests by default: seelogin_scopesfor why the default is small. A token keeps whatever it was granted, so a build that widens this list needs onegrr auth loginto take effect. - scopes_
for_ service - Every scope one service’s methods declare for
grr auth login --service. The index is the same source the command tree andgrr api describeread, so the set matches exactly what that service can be asked to do — and stays far below the size at which Google’s consent screen stops submitting.Nonewhen the index has no such service.