Re: KeyError: 'refresh_token' error in fetchmail-oauth2

A somewhat more technical question about this.  Does the approval
mechanism for unverified applications
(https://developers.google.com/apps-script/guides/client-verification)
not work? Or is the problem other non-technical policy issues or
potential future problems with an approval mechanism that technically
works today?  My apologies that I've not invested the time in setting
up and testing fetchmail 7 to verify whether the documented approval
mechanism works or not with fetchmail.

R Horn
[email protected]

On Sat, Apr 16, 2022 at 3:45 AM Matthias Andree <[email protected]> wrote:
>
> Am 13.04.22 um 23:55 schrieb Andrew C Aitchison:
> > On Wed, 13 Apr 2022, Matthias Andree wrote:
> >
> >> Am 12.04.22 um 23:18 schrieb Marco Gaiarin:
> >>> Juergen Edner say that the OAuth client created in 'Test mode' least at
> >>> maximum a week.
> >>> But if i try to publish the app, i need the Google approval process,
> >>> because
> >>> the api used (eg, GMAIL API) is 'restricted'.
> >>>
> >>>
> >>> So, it is needed to publish the app? If yes, what is the shortest
> >>> and error
> >>> prone path to get it approved?
> >>>
> >> Their requiring registration of the "app" (we have never called
> >> fetchmail that) - and not solely the user for his or her own account -
> >> is one of the reasons why I say that OAUTH2 in this form is generally a
> >> non-starter and does not scale.
> >>
> >> I cannot possibly register fetchmail with each and every mail service,
> >> and device registration is somewhat pointless anyways.
> >
> > There is a point to it. If you usually use fetchmail to access gamil,
> > then gmail receives a login as you from, say, Outlook then gmail will
> > be suspicious and look harder, perhaps look whether the connection is
> > from a country and a computer/device that you have never used before.
> > I believe that they can choose to block the connection even if the
> > password
> > is correct, and warn you when you login from your usual computer.
> >
> > Yes, this is a pain, but there is a good reason behind what they are
> > trying it do, as well as good reasons to complain about it.
>
>
> Andrew,
>
> Thanks. But none of what you mentioned or relay as their intention makes
> any good point to me why registering an and receiving approval for an
> application with a service is required. GMail specifically offers
> 2-factor authentication.  That can happen without registering *MY*
> implementation aka. fetchmail with them.
>
> To me it still looks that the decision to register the app itself is a
> political issue about exerting control and being discriminatory about
> what clients people can use, and is not about security.
>
> So if the abomination of hundreds of pages of a "standard" just for
> authentication by itself does NOT suffice to implement OAuth2, then we
> should probably leave it out and remove the experimental bits that are
> in fetchmail's code before a release, even from contrib, and replace
> them with a document README.OAuth2 that starts with "why does fetchmail
> not implement OAuth2".
>
> Or else somebody show me to a mail service that is not just some SOHO
> site and that *does* implement OAuth2 without requiring jumping through
> arbitrary hoops and showing dressage tricks or play sit up and beg or
> something, then we can implement it and document "why you cannot use
> OAuth2 with Google" instead.
>
> Regards,
> Matthias
>
>
>
> _______________________________________________
> Fetchmail-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/fetchmail-users



-- 
Robert Horn
[email protected]