insanum / gcalcli

Google Calendar Command Line Interface
MIT License
3.33k stars 314 forks source link

Proper support for alternate auth accounts #807

Open dbarnett opened 1 month ago

dbarnett commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 2 weeks ago
[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 commented 2 weeks ago

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 commented 1 week ago

config.toml would be the default.

For other.toml, options could be:

dbarnett commented 1 week ago

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

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 commented 1 week ago

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 commented 1 week ago

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 commented 6 days ago

K then a few things:

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 commented 6 days ago

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.