Switch to oauth2-auto for Google Calendar OAuth2

[telotortium]

This allows switching from the deprecated OOB flow
https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html#disallowed-oob,
fixing #191.

As a side effect, oauth2-auto makes it straightforward to support
multiple accounts (see
#199), although this
PR doesn't by itself enable that.

@rhaps0dy

[telotortium]

@rhaps0dy would you mind putting oauth2-auto on Melpa? I could also do it if you don't have time. See https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org.

[telotortium]

All tests now pass except for 26.1, because oauth2-auto is not marked compatible with it. I've opened rhaps0dy/emacs-oauth2-auto#1 to try to fix this.

[telotortium]

Now passes, but only if I manually install rhaps0dy/emacs-oauth2-auto#1. If there's no response to that PR soon, I will vendor this dependency and merge.

[jackmac92]

thanks for the work on this!!

[deen1]

Hi, sorry to butt in, but will this be merged in the next couple of weeks? I think we're coming up to the October 3rd deadline for OOB migration.

[rhaps0dy]

Oh, i wasn’t aware of that deadline. very possible, there’s 1 month left. I’m trying to get oauth2-auto verified by Google and into Melpa, @telotortium has done the lion’s share of the work there. In any case there already exist workarounds so you don’t have to stop using org-gcal. Adrià Garriga-Alonso

…

On Sep 6, 2022, at 08:56, deen1 ***@***.***> wrote:  Hi, sorry to butt in, but will this be merged in the next couple of weeks? I think we're coming up to the October 3rd deadline for OOB migration. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[deen1]

@rhaps0dy Thanks for your reply! Very grateful to you and @telotortium for your work on this.

Re:

In any case there already exist workarounds so you don’t have to stop using org-gcal.

Sorry for being obtuse, but I haven't yet found a suitable workaround, and there aren't any highlighted on the README. Could you point me in the right direction?

FYI this is a portion of an email Google sent me a few months ago -- there's the possibility of extending to February of next year, and "testing mode" apps will not be affected, but October 3 looks like the deadline.

Starting October 3, 2022, we will block OOB requests to Google's OAuth 2.0
authorization endpoint for existing clients. Apps using OOB in testing mode
will not be affected. However, we strongly recommend you to migrate them to
safer methods as these apps will be immediately blocked when switching to
in production status.

Note: New OOB usage has already been disallowed since February 28, 2022.

Below are key dates for compliance

September 5, 2022: A user-facing warning message may be displayed to
non-compliant OAuth requests
October 3, 2022: The OOB flow is blocked for all clients and users will see
the error page.

Please check out our recent blog post about Making Google OAuth
interactions safer for more information.

What do I need to do?

Migrate your app(s) to an appropriate alternative method by following these
instructions:

Determine your app(s) client type from your Google Cloud project by
following the client links below.
Migrate your app(s) to a more secure alternative method by following the
instructions in the blog post above for your client type.

If necessary, you may request a one-time extension for migrating your app
until January 31, 2023. Keep in mind that all OOB authorization requests
will be blocked on February 1, 2023.

[rhaps0dy]

Instead of calendar-id it should be the user's email.

It works if the string is garbage (because it's only a login_hint internally) so you haven't noticed the error. But this will make you log in for every calendar you have, whereas if you have the same string every time you'll only log in once.

[rhaps0dy]

Note also that the PR 9, which I'm going to merge at some point, changes the format to (oauth2-auto-access-token "[email protected]" 'org-gcal '(calendar))

[rhaps0dy]

@deen1 ,

haven't yet found a suitable workaround, and there aren't any highlighted on the README. Could you point me in the right direction?

The easy way is to install org-gcal from this PR, and install oauth2-auto from its repo. You will also have to upgrade deferred to its latest version.

The resulting software has rough edges but it's kind of usable :)

[rhaps0dy]

Ideally you'd just be able to use 'google and let oauth2-auto handle everything. I understand that this way it is possible to use the existing org-gcal-client-id and org-gcal-client-secret, but if Google verifies oauth2-auto, it's going to be much easier to just use its ID and secret. One more thing not to worry about :)

[telotortium]

Does it still work to use one secret for all clients of the library?

[rhaps0dy]

Do you mean: if more than one program uses the library, can they all use the same secret?

I think so, and it's also nicer for the user because they only have to log in once. We'll have to verify scopes for all the possible libraries on that secret though.

For existing users of org-gcal maybe it's better to do it like you have done it now, though. This way they don't have to modify the config.

Does this answer your q?

[rhaps0dy]

Note also that the PR 9, which I'm going to merge at some point, changes the format to (available_scopes . (calendar . "https://www.googleapis.com/auth/calendar"))

[deen1]

@rhaps0dy Thanks very much! I'll probably wait to see you guys push the full thing before the deadline, but I'll have a look at your suggestions above later this week.

[telotortium]

I think so. I'll look again tomorrow

…

On Sat, Sep 10, 2022, 17:31 Adrià Garriga-Alonso ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In org-gcal.el <#200 (comment)>: > @@ -2282,6 +2160,24 @@ non-nil." (plist-get plst :year)))) +(defun org-gcal-reload-client-id-secret () + "Setup OAuth2 authentication after setting client ID and secret." + (interactive) + (add-to-list + 'oauth2-auto-additional-providers-alist Do you mean: if more than one program uses the library, can they all use the same secret? I think so, and it's also nicer for the user because they only have to log in once. We'll have to verify scopes for all the possible libraries on that secret though. For existing users of org-gcal maybe it's better to do it like you have done it now, though. This way they don't have to modify the config. Does this answer your q? — Reply to this email directly, view it on GitHub <#200 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANMVDK77NHARLNSPX4B7VTV5UR4RANCNFSM52PSDOYA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[telotortium]

@rhaps0dy Any luck with getting Google to verify your library?

[megodoonch]

Thank you for this! It might be exactly what I need.

I have miraculously managed to, I think, follow your instructions to install the oauth2-auto branch of this fork, and the oauth2-auto as well. I don't really know how it's supposed to work, though, so I'm wondering: is it supposed to make and write to ~/.emacs.d/oauto2-auto.plist? I don't have one being made, and when I turn on the error tracking, I see errors related to the non-existence of the file, and if I touch the file first, the lack of content. What am I doing wrong? Do I need to write the file myself somehow before I use org-gcal-fetch?

More details: I successfully log into the account (I get the "Authentication token successfully obtained by Emacs! You may close this page now." message) but when I return to Emacs I face weird errors like "wrong number of argments" given to time-date. Toggling on the error tracing gives the errors described above. I also had a lot of trouble getting cask etc to work, so something weird might have happened during installation of some parts.

Thanks for any help!

[megodoonch]

Also: moving to my home computer, where I have emacs 27 rather than 26.3, org-generic-id throws an "invalid function" error:

Debugger entered--Lisp error: (invalid-function (file (car-safe (org-generic-id-files-modified-since-modtime (org-generic-id--last-update-id-time-get id-prop) (list file) org-generic-id--files))))
  (file (car-safe (org-generic-id-files-modified-since-modtime (org-generic-id--last-update-id-time-get id-prop) (list file) org-generic-id--files)))()
  org-generic-id-update-id-locations("entry-id")

But when I walk through the function with a debugger, it works just fine and instead I get a mysterious error about the arguments to time-date after logging in to Gmail.

I'm not sure if this is the place to report things like this, but, well in case it's useful, here it is!

[telotortium]

@megodoonch Thanks for the feedback - I'll try looking into this tonight when I have some time

[max6166]

I have miraculously managed to, I think, follow your instructions to install the oauth2-auto branch of this fork, and the oauth2-auto as well.

How do you download the oauth2-auto branch of this fork/PR? I'm not familiar enough with Github to find it.

[megodoonch]

I have miraculously managed to, I think, follow your instructions to install the oauth2-auto branch of this fork, and the oauth2-auto as well.

How do you download the oauth2-auto branch of this fork/PR? I'm not familiar enough with Github to find it.

Yeah, that took me a few tries! When you clone someone else's repo you only get the main branch by default. I think there were two ways that worked:

1. Clone the branch directly
2. If you already have the repo, git fetch the other branches, then switch

for 1, try

git clone --branch oauth2-auto https://github.com/telotortium/org-gcal.el.git

For 2, I think it was this:

git fetch --all  # get all the branches
git branch  # check it worked
git switch oauth2-auto  # switch to this branch

[telotortium]

Hi everyone, I'm planning on merging this branch as-is. I've decided to work around the fact that oauth2-auto isn't on MELPA yet by just vendoring it inside this repo.