Post by Adam H. KermanEduardo's Web page doesn't include steps to be taken on the Google
Account side first. btw, if alpine is able to reach Gmail in background
after supplying the 16-digit passcode generated by Google, you will not
see the page with the giant URL.
Adam, let me tell you the story so you can tell it later correctly. This
message became very very long. I apologize for the length, but the story
is long.
What Alpine does, when connecting to any server, is to compare the
authentication methods in Alpine with the authentication methods supported
but the server, and then sorts them in some preference system which is set
up at compile time. At the moment of this writing, the PLAIN authenticator
comes before the bearer, which comes before auth2.
This means that if Gmail allows you to use Plain, Alpine will use it.
There is no set up to make for this, except for that setting of allowing
less secure apps, but that has nothing to do with XOAUTH2. For Bearer and
XOAUTH2 you have to make the same set up.
I have never used a app password in alpine, but I imagine it is a special
password that goes to gmail using the plain authenticator (that would make
sense to me) so if you are using one already, Alpine will use that one
immediately.
In other words, if you are already using PLAIN authentication, you do not
need to shift to using OAUTH2, for example. It is only when Gmail says no
to PLAIN authentication that either Bearer or OAUTH2 come into play.
HOWEVER, users can override all of this. Version 2.22 allows you to use
the XOAUTH2 authenticator EVEN if you are already using a password
provided by Gmail, and both can coexist peacefully in your password file.
This is because internally Alpine saves XOAUTH2 passwords differently than
PLAIN authentication passwords, because they are intrinsically different
types of object, so it makes no sense to replace one by another. In
addition, there is an option to add /auth=xoauth2, or /auth=plain to the
definition of a server to force the authentication that you want. So if
you do not want to try XOAUTH2, simply add /auth=plain to your gmail
settings.
I do not know, but I suppose that an app that uses XOAUTH2 is not less
secure.
Post by Adam H. KermanGoogle overrides your setting "Use Less Secure Apps" for your
inconvenience, forcing you to turn it back on if you don't want to use
XOAUTH2.
Before you can use alpine as a "More Secure App", using XOAUTH2,
1) Turn on two-factor identification.
I wrote the code for XOAUTH2 and I never had to do this before, during or
after testing. I used a vanilla gmail account (not a company account) and
I never had to turn on two-factor identification.
Post by Adam H. KermanVERY IMPORTANT
If you are saving passwords in ~/.pine-passfile AND the passfile is
encrypted, DO NOT supply the passkey to decrypt the file. You need to
force alpine to store and overwrite your existing password with new
credentials and storage of the passcode generated above for OAUTH2.
As I said before, this is not necessary. I currently have passwords for
PLAIN and XOAUTH2 authentication in the password file. It is all about how
you play the game, but this is definitely not necessary. Use /auth=XXXX
instead. Much simpler.
Post by Adam H. KermanSet up IMAP and SMTP for Gmail in SEPARATE alpine sessions.
1) Follow Eduardo's instructions for setting up a new account.
I will have to come back to this later on. As I mentioned before, I never
had to set up anything separately. That would have been a design disaster.
No it cannot work like that. I would oppose anyone designing a system this
way. I set up the IMAP server and the SMTP server correctly, and then
login to the IMAP server first (because of tradition, not because of
need). Alpine knows internally that both servers use the same credentials,
so giving one password for one server gives the password for the other.
This is only for XOAUTH2, not for PLAIN authentication. This means that
once you set up your access using XOAUTH2 for one server, you do not have
to repeat it for the other. Alpine knows what to do.
There is more to this later, but here is the bottom line: The design of
the interface was thought such that if you simply configure the servers as
they appear in the web page, and follow the directions specified in the
web, then everything should magically work (and it does, except for
another reason which I will explain later!)
I removed lots of text written by you about how to set up Alpine. Please
try to forget about this, and let me try to explain what works, how this
is supposed to work, and what can users do to make it work when it does
not work.
First things first: Set up your servers exactly as follows:
inbox: {imap.gmail.com/ssl/user=***@id.com/auth=xoauth2}INBOX
smtp: smtp.gmail.com/ssl/user=***@id.com/auth=xoauth2
In theory the second step is to follow the directions that appear in my
page, at
http://alpine.x10host.com/alpine/alpine-info/misc/xoauth2.html
but somehow they do not work. The reason is because Google stopped
allowing people to use the client-id and client-secret that alpine got
from Google because they put Alpine as an "unverified app". Google has
their reasons to do so. In general, it prevents that a malicious app
abuses the information it can collect from its users. Google requires that
apps be verified, and I tried to make Alpine go through the verification
process, just to find out that it is not possible for me to complete that
process, and I showed in a video to Google that what they are asking me is
not possible to do because of the way that they set up the verification
process, and even in that case I was ignored, so Google is playing big
guy, and Alpine little guy, and big guy is ignoring little guy because it
can.
Just to be clear, in case you ever hear Google's version. They were hung
up on Alpine not having a privacy policy, and not having terms of use. I
told them that their process eliminates Alpine before I could write those
terms. In other words, I showed google that even if I wrote those terms,
and I tried to go through the only path that they allowed me to go, I
would still not be able to complete the process, because the obstruction
for me was not the privacy policy, it was them rejecting the server, and
there was not way to get past that, so privacy policy or not, there was
nothing for me to do, and I quit talking to a company with deaf ears.
So, if Alpine were a verified app then the steps described in my page
about configuring Gmail with XOAUTH2 would actually work. In fact, it
works for 100 gmail accounts today, as that is the maximum number of users
Google allows for an unverified app.
While I was talking to Google about this, they suggested that Alpine users
do the same as mutt users do to use XOAUTH2 with Gmail. I will describe
this generically, and it is not for the faint of heart, but I was told
that Alpine users had the option to register Alpine as their app, and so
obtain a client-id and client-secret, which is really all that Alpine
users need in order to use Alpine with Gmail in XOAUTH2. Since every
unverified app can be used by up to 100 users, it would be possible for
every user of Alpine to register Alpine as an app with Gmail and then
share their client-id and client-secret with others and still have access
to Gmail.
So how is a person supposed to register Alpine with Gmail? Hold tight,
this is what Google wants you to do:
* Login to https://console.developers.google.com with the same
credentials that you use to login to your gmail account.
* Register Alpine. You need to allow Alpine access to the scope
https://mail.google.com/. Other scopes I have set up are "email,
profile and openid". The one that Google cares about is
https://mail.google.com. That is where the issue really is.
* Once you have registered Alpine, go to create OAUTH credentials for
Alpine. You will be given a client-id and a client-secret.
[ I did this a long time ago, and I do not recall the exact steps to
do this, but this is the correct order in which to do this.]
* Copy those values, and add them to Alpine. This is done in the screen
that you get by pressing "M S U". I had to add this screen because
Google did not allow me to submit Alpine for verification, so I had to
write the code, just before releasing Alpine, so that users could use
Alpine with XOAUTH2, albeit, not the way it was intended originally.
* Once all of this has been done, you can open an IMAP or SMTP connection
and follow the steps in my web page to configure Alpine to use XOAUTH2.
Yes, please send a thank you note to Google for making you waste your time
trying to figure out how an end user is supposed to register an app, which
is a highly technical thing. Google said that mutt users were supposed to
do that, hence Alpine users will have to do that too. It is only fair!
After all Alpine users do not have any other thing to do than trying to
figure out how to navigate the registration process, instead of writing
research papers, monitor computing systems, or just simply be
discriminated because they cannot use their own senses to access the pages
in the google site that are required to register Alpine as an app. I have
no idea how a blind person is supposed to do any of this process, and
Google could care less about leaving them out, just because they have deaf
ears, and they think that their good and bad reasons is all that matters.
So if I did not lose you. The point is very simple:
* Set up the gmail servers exactly as above
* Get some client-id and client-secret from somewhere
* Add those values to alpine in the "M S U" screen
* Go through the process in my web page to configure Alpine to use Gmail
with XOAUTH2
Alpine will take it from there. I hope some day steps 2 and 3 will not be
necessary, but today they are. Sorry for the rant, but you probably need
to know what happened so that you understand why you are wasting your time
so much trying to make this work. I tried to make it as easy as possible
for everyone, but Google trumped me.
--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)