Open dbarnett opened 4 weeks 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"]
?
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".
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
.
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.
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.