Adding OAuth2 authorization to and existing program!

Hello Everybody!,

Has anyone taken an existing network program, (say a mail checker), that worked just fine prior to the advent of 'OAuth2', and added OAuth2 authorization to it? I would like to hear of any successes doing so in either Python3 or C. I've begun assembling some resources for doing that, but there are a lot of nuances to consider with the code that i have to start with first.

The reason that I'd like to discuss this is that it seems to me that most or all the available mail checkers Don't have the capability, and the authors/maintainers don't appear to think adding that capability is worth it? OAuth2 has been getting more pervasive for Years now! I know there are some 'workarounds' to this issue, but the mail providers could change/drop that at anytime. There may be an updated mail checker Somewhere, but I have searched for one everywhere in the known net-sphere without any success. Also , it looks like the libraries, et al, for both these languages are available to aid this type of project. Adding the OAuth2 authorization flow to the existing body of code should be straight forward once understood.
I'm studying two separate checkers, one written in Python3, and one in C, each one worked Fine, but choke now on OAuth2 authorization mail provider logins. It's no longer just Google, my ISP (a Giant Communications Consortium) has drunk out of that well too.

I would like to get some thoughts and ideas from anyone interested!

Hello,

I remember you asking this question a while back as well, and I didn't respond at the time as I didn't really have anything useful to add unfortunately. But since you went to all the trouble of coming back and asking again, I've spent a bit of time on this, and have made a little progress, though I suspect it's not quite going to be the variety of progress you're looking for. Anyway, here's what I've found.

Generally when on a *NIX system, I like to use Alpine as my mail client. I do have a GMail account, though I seldom use it, and have a Pine .pinerc file set up to access my GMail. Or I did - as you describe, that now doesn't work, due to the various little "We'd like you to use our mail client please"-style roadblocks that Google have put in the way.

However, the latest version of Alpine, 2.26, seems to have support for the current GMail login mechanism, albeit in a very kludgey and horrible way. Step by step, here's what I did to get this working:

  1. I built the latest Alpine from source, grabbing it straight from https://alpineapp.email/.
  2. I ran alpine -v on my existing system to get the configure string that had been used by Red Hat when they built it (I'm testing on a CentOS 7.x system), and used that same set of options, albeit with a new prefix of /usr/local so it wouldn't clobber my existing Alpine RPM install.
  3. I then did a regular make / make install
  4. I re-ran my new local Alpine binary with my existing GMail-compatible .pinerc file, and it provided me with a URL to copy-and-paste into a Web browser
  5. I did that, which then took me to Google's account system. I logged in, and was ultimately re-directed to a bogus non-working URL beginning with http://localhost. That's fine though, and weirdly is actually what we want.
  6. I copy-and-pasted that non-functioning localhost URL back into my Alpine terminal window, first pressing "C" to enter the code
  7. And that was that - I then had access to my GMail Inbox.

It must be said that this is not the only set of hoops I had to jump through. Many months/years previously, I had to go through the trouble of getting OAUTH2 working with Alpine in the first place. That involved setting up a Google developer account, registering my own local install of Alpine as a Google application, and getting a set of keys and credentials that I could copy-and-paste into my Alpine .pinerc file for Alpine to use for authentication. I did all that so long ago that I can't recall the step-by-step sequence there, sorry. I do recall just following the steps I found on the Web for doing this though, so hopefully it won't be too tricky for you to set up.

Anyway, the end result of all this is that you'll be able to run a currently-still-working-until-they-think-of-another-way-to-break-it-again Linux mail client in a terminal window, and said client will beep when a new e-mail comes in.

Not great, I know, but it's the best I currently have to offer in terms of a semi-passable solution. If anyone else has any ideas I'm sure they'll chime in, but to be honest I strongly suspect that most people have just thrown in the towel on this one and are using either the GMail Web page or GMail on their phone and/or tablet to read their Google mail these days, due to how difficult Google are making it to do anything else.

Hope this helps !

EDIT: Just realised you're not actually directly trying to access a GMail account, but rather another OAUTH2-enforced mail system. Given that Alpine does support OAUTH2 login as a mechanism however, I'll leave all of the above intact and as-is, since much of the info there may still be useful to you in any case (or to anyone else who wanders along trying to get a Linux terminal mail client working with GMail).

4 Likes

@drysdalk,

Thanks for your input, yes that is Interesting!
I use two email clients (MUA's) Thunderbird on the desktop, and Mutt on the CLI.
There is a process of 'hoops' to jump through to get Mutt to authorize also, similar to your description of Alpine. Indeed both mail clients work without any issues now. This led me to
find a solution to the broken 'checkers' issue. I also have only two mail providers, GMail,
and my ISP, a True Corporate Monstrosity that seems to lose touch with the 'people' more
and more rapidly now that they believe they're always right? ( My perception)! ;^)

What really amazes me the most is that some of these 'checkers' are Very Cool, with support
for SSL/TLS, IMAP, POP, Local Mail mbox / maildir formats, Everything but OAuth2!
Both of these checkers also feature GTK3 front ends (for configuration) which does mean More code mods to configure the OAuth2 enhancement/s, but, that's what programmers Do!
It's a darned shame to see these programs essentially trashed in the name of 'Corporate Progress', regardless of whatever the merits or demerits of OAuth2 may or may not be?
This is a project I can do. I was hoping to not to have to modify much or any of the existing
code body of the checker that I decide to use, but I see that it's probably inevitable. Just bolting on a 'kludge' is not the method for doing this one.

I will take a look at Alpine too, it sure appears to have similar methodology that the Mutt fix
uses. And, thank you, I appreciate your taking time to relay your experience with Alpine!

A Long time ago I used 'pine' for a while from the University of Washington? Seems it worked well enough, but IIRC they just didn't want to free the license up, so I said 'screw it' and moved on, eventually deciding on the Mutt MUA for systems with no GUI at all. These days even on GUI systems I still find myself shifting to 'SysV Level 3 or multi-user.target' just because that's where I come from, and to get rid of the excess baggage. Quaint, but I Like it!
I'm glad you mentioned CentOS, I was hard core Red Hat / Slackware for years, but now am a diehard Debian / BSD fan. I'm not a fan of 'systemd' trying to encroach on the BSD world though, but I'm getting way Off the mark here!

Cheers!

For anyone interested in Google specific OAuth2 API stuff this might be of value:

Using OAuth 2.0 to Access the Google API:
https://developers.google.com/identity/protocols/oauth2

Other API's will have variations/nuances of their own to deal with though!
Google was only the Beginning of this syndrome. Many other providers are
now following in their footsteps as well.

1 Like

This topic was automatically closed after 5 days. New replies are no longer allowed.