Re: Making GNUS continue to work with Gmail

[T.V Raman]

Cesar Crusius <cesar.crusius@gmail.com> writes:


Also, as Ceasar points out, different hosting apps vary in this flow.
Twitter uses OAuth2 but is easier to configure -- witness
twittering-mode.

The other wrinkle with the Google Oauth2 flow is that you cannot
complete it without resorting to a full-blown JS-powered Web browser,
i.e. even if we implemented everything on the emacs side, you would
still need to hand a URL to Chrome Or Firefox to get to the screen that
generates the allow/deny button. At that point, you'll get the refresh
token that you'll need to painfully extract and squirrel away somewhere
--- you can then forget about it until at some future point, some
unforeseen accident invalidates your refresh token at which point you
need to go through the whole flow again.


> Michael Anckaert <michael.anckaert@sinax.be> writes:
>
>> Cesar Crusius writes:
>>
>>> Richard Stallman <rms@gnu.org> writes:
>>>
>>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>>
>>>>   > The person you want to reach out to is probably
>>>>   > dvratil@kde.org. Here's a relevant blog post from him, about how
>>>>   > he fixed the Kontact Oauth2 problem:
>>>>
>>>>   > https://www.dvratil.cz/2019/08/kontact-google-integration-issue/
>>>>
>>>> Lars, is this something you can do?
>>>>
>>>>   > My auth-source-xoauth2 package "avoids" that by having every user
>>>>   > do the API key dance with Google, and as a result is rather hard
>>>>   > to setup.
>>>>
>>>> Aside from the inconvenience, is there anything about this we simply
>>>> cannot ask users to do?  Does it require accepting terms that are
>>>> unjust and not required for using Gmail itself?
>>>
>>> I went through the process a long time ago, so I can't answer that
>>> with certainty. The current legalese is in the pages here:
>>>
>>> https://developers.google.com/terms
>>>
>>> Somebody with a keener legal eye could look at it, but there are
>>> certainly more/different terms there.
>>>
>>> As an aside, it is worth noting that my package is not
>>> Gmail-specific. It could be used for the Reddit example given before
>>> via similar means: register a project/app in Reddit, get the keys,
>>> etc.
>>>
>>> The crux here is that there needs to be an app - their intent is
>>> that the software producer (in this case an "Emacs" or "Gnus")
>>> registers an "official" app, and the app manages its secrets in a
>>> way compliant with their terms (which we already know is pretty hard
>>> for OSS projects).
>>
>> I've picked up this discussion from the list archives and decided to
>> chime in with some information I have. Since I lack the previous
>> emails in this discussion, please excuse me replying out of sync.
>>
>> Including the client ID / secret key in Emacs source code (as
>> Thunderbird does) is bad practice. In addition, I believe there might
>> be some legal / moral issues with registering an FSF application under
>> the Google TOS.
>>
>> The only suitable alternative would be to have the user register his
>> own Google Cloud Project and use that client ID to run the OAUTH2
>> flow. This approach differs in that instead of having one client and
>> many users, we have one client for every user.
>
> This is exactly what the auth-source-xoauth2 package asks the user to do, 
> with documentation on how to do it *for Google projects.*
>
>> In the past I've written a number of software packages for companies
>> that had to make use of Google API's using OAUTH2 authentication. In
>> some cases we couldn't include the client secret in those packages
>> (various departments had their own Google Cloud projects and API usage
>> guidelines). So in essence I had the same issue as what Emacs is
>> facing now.
>>
>> The solution was to have the software prompt the user to create a
>> specific project on Google Cloud and specify the client secret in the
>> application configuration. A similar approach could be chosen for
>> Emacs so that instead of having a single client ID for Emacs, every
>> user creates his/her own project and configures the client ID in
>> his/her Emacs configuration. Then the OAUTH2 flow has to be run for
>> that 'Emacs application'.
>>
>> The flow as I once implemented it could be adapted to Emacs as follows:
>>
>>  * The Emacs documentation specifies the user what type of Google
>> Cloud project has to be created and what client ID / secrets have to
>> be configured.
>>  * After configuring this information, the user starts an Emacs
>> command (eg M-x retrieve-oauth-credentials)
>>  * This command starts a local webserver and opens the address in the user's 
>> browser
>>  * The webpage displayed allows the user to start the OAUTH2 flow
>> which redirects to the local webpage with the OAUTH2 token
>>  * Emacs stores the OAUTH2 token in a suitable location
>>
>> I would have to check back to some code I have stored to verify the
>> entire flow and make sure I didn't miss anything. But in essence the
>> flow above is what would be required.
>>
>> If deemed suitable, I'm willing to aid in development of this feature
>> if someone can spend some time mentoring / guiding me on the required
>> steps and correct implementation details.
>
> One worry I have about this is that it wold be very Google-specific,
> as there are other places where this is necessary (Reddit came up as
> an example) that have a quite different project registration workflow.
>
> The impression I get from all the discussion is that, in the end,
> OAUTH2 is just extremely OSS-unfriendly, and currently there may be no
> better solution than simply say "go register a project and generate
> the keys" in various levels of detail.
>
> My personal take on this is that documentation serves the purpose
> better, but I'm not against utility functions that guide you through
> the setup. I know, for example, that the Google Cloud Developer
> console is *extremely* accessibility-unfriendly, to the point of being
> unusable (T.V. Raman can correct me here if I'm exaggerating) - the
> workflow you sketched above would not solve that problem, as the user
> still has to navigate the Google interface to do things.

--