Proper support for alternate auth accounts

[dbarnett]

There should be a convenient way for users to switch between different authenticated accounts in gcalcli.

Currently this can be done by twiddling oauth files (see #805), but the mechanism is clunky and not very discoverable. The ideal would probably be to have a set of named auth accounts and to be able to configure --account=someaccount@domain in cli args and config files.

[dbarnett]

Or maybe instead of separate configs per account, the config.toml structure should change to support e.g.

[accounts."account1@domain".calendars]
ignore-calendars = ["cal1", "cal2"]

?

[dbarnett]

I hit one snag that the oauth tokens we receive don't seem to include an account name or email to identify separate accounts. It seemed like the openid and …userinfo.email scopes might help get that included (relevant OAuth docs), but I haven't quite figured out how yet, and requesting more than one scope seems to make the auth flow more complicated with checkboxes on the scopes you have to make sure to manually check.

Alternatively we could just let users manually name the accounts and store one unnamed one as "default", like:

$ gcalcli init
…
Successfully loaded credentials for account "default".

$ gcalcli init --account=work
…
Successfully loaded credentials for account "work".

[dbarnett]

K for reference, I was able to successfully fetch account ID / email using their recommended way from google_auth_oauthlib docs:

flow = InstalledAppFlow.from_client_config(
    …
    scopes=[
        "openid",
        "https://www.googleapis.com/auth/userinfo.email",
        "https://www.googleapis.com/auth/calendar",
    ],
)
session = flow.authorized_session()
profile_info = session.get(
    'https://www.googleapis.com/userinfo/v2/me').json()

but I can't figure out how to get it to require multiple scopes like that w/o the annoying checkboxes and am leaning towards just letting users explicitly assign names to the accounts like gcalcli init --account=someaccount2.

[ahughes03]

I like the idea of using an --account flag to define the location of the oauth/config files. Previously, I ran two commands in my conky config to see calendars from two separate accounts. An --account flag should allow my use case to work again, provided the flag works with other commands like list, agenda, etc.

[michaelmhoffman]

[accounts."account1@domain".calendars]

This seems unnecessarily complicated to me. Having a different toml files for each account is a lot easier to understand. If you want to avoid duplication in configuration, it maybe be better to have config.toml included by default, with any changes in other.toml overwriting it, but others copying the config.toml configuration.

[dbarnett]

Eh, could be I'm overcomplicating things. My priority in however it's specified is to remove any temptation for people to manually twiddle oauth files, so we're not locked into some implied contract of where these files need to live.

How would these "config.toml" and "other.toml" files be specified when you're invoking gcalcli though?

[michaelmhoffman]

config.toml would be the default.

For other.toml, options could be:

• --config=other.toml
• --config=other
• --config=account@domain (and the file would need to be called something like [email protected])

[dbarnett]

Might work okay. I suspect that'd also end up having a lot of complications in practice:

• It still needs to have some 1-to-1 mapping between the config and the account auth token for gcalcli to work properly
• What commands do you actually run to set up a new account?
• Would a secondary config "replace" or "extend" options like ignore-calendars?

Granted these are all details that need to be figured out for pretty much any strategy, but could start getting really messy really fast using implicit mappings or magic names.

[ahughes03]

I agree with --config=other.toml being a good way to invoke another instance.

In an ideal world, if I ran gcalcli init --config=sports.toml a new config called sports.toml would be created with a reference to that specific account auth token. Then, in the event that any subcommand is issued with the --config flag, it would refer gcalcli to that instance (meaning the secondary config would "replace" rather than "extend" options like ignore-calendars. They would be completely separate instances.

Ultimately, I'd think that the .toml would need to have an explicit reference to the account auth token to ensure 1-to-1 mapping.

[michaelmhoffman]

Upon reflection I think --config=other.toml is the best option as it makes it easiest for the uninitiated to understand what is going on, and enables config files outside the standard config directories if a full path is supplied.

gcalcli init --config=sports.toml

Good idea! Should be gcalcli --config=sports.toml init though 😉

[dbarnett]

K then a few things:

• From the cli command I wouldn't guess that's triggering an account switch, so maybe rename the arg to --account-config or something?
• +1 having an explicit reference to the account token in the generated config will be helpful
• Are we imagining this arg as a full path? There'll be a few more little complexities to figure out for that
• Will want clear setup instructions for this since parts of it don't exactly feel self-documenting

BTW the recommended way of pointing to an explicit config file / dir is $GCALCLI_CONFIG and that should be fine as-is. Could use an env var for this account config thing too, but I kinda prefer an explicit arg for the init case.

[dbarnett]

I also realized init could just prompt you for whether to overwrite the default account or set up an alternate. That would make it friendlier having it suggest new file paths you could edit instead of having to figure out everything upfront as cli args.