Closed ferdinandyb closed 1 year ago
On Tue, Nov 29, 2022 at 02:21:50PM -0800, Bence Ferdinandy wrote:
One difference I found was the redirect URI, but changing that to the same on as in the mutt script made MS complain that the redirect uri is not the same as is configured for the client.
The scope parameters differ too: "office365.com" vs "office.com" Also, see below.
Another very obvious difference is that in the mutt script I can tell it which sasl method to use, that is
oauthbearer
for gmail andxoauth2
for outlook. Indeed ofmailctl
only supportsoauthbearer
that might explain the whole issue.
No, this sasl_method
parameter is not used either in the process of
authorization
or of renewal
. That is not part of the API mailctl using.
It is in the mutt_oauth2.py
only for testing a (not expired) access token
with smtp, imap etc. protocols.
However, there is an extra parameter passed to the API in the case of microsoft: 'tenant': 'eltehu'
That might be the real culprit for mailctl does not deal with this possible parameter at all.
I'll look into this ...
On Wed Nov 30, 2022 at 22:33, Peter Dobsan wrote:
However, there is an extra parameter passed to the API in the case of microsoft: 'tenant': 'eltehu'
That might be the real culprit for mailctl does not deal with this possible parameter at all. You are probably quite right, now that I think about it :)
I'll look into this ... Thanks! Would be nice to be able to handle everything with
mailctl
.
Wow, github mobile absolutely butchers comments posted via email, even though they look ok on the desktop ... Anyway, let me know if I can help anything. I poked a bit around the codebase, but I don't know any haskell so I didn't really find my way unfortunately.
On another note: I'm planning to write a guide about setting up terminal based email sometime this month. It would be much more concise if I could leave out the mutt script altogether and just have mailctl in it for oauth authorization. So this is just an absolute no pressure question of whether you think you have the time to tackle this this year or not. If you think it's possible soonish, I'd be happy to wait for it. Setting up email is already pretty involved, so cutting some noise would be great :)
On Mon, Dec 05, 2022 at 01:11:51PM -0800, Bence Ferdinandy wrote:
mailctl in it for oauth authorization. So this is just an absolute no pressure question of whether you think you have the time to tackle
I just love such "no pressure" questions.
this this year or not. If you think it's possible soonish, I'd be happy to wait for it. Setting up email is already pretty involved, so cutting some noise would be great :)
Tell you what, while you are waiting why don't you follow up on what you mentioned in another (now closed) issue's thread: https://github.com/pdobsan/mailctl/issues/17#issuecomment-1331398198
I just love such "no pressure" questions.
:D I really meant no pressure, I think it would be perfectly reasonable if this would not be your preferred end-of-year activity :) So I was really just interested in it if you plan to do it or not and then plan accordingly.
Tell you what, while you are waiting why don't you follow up on what you mentioned in another (now closed) issue's thread: #17 (comment)
It's on my todo list for soonish, although I will probably have to wait at least a week after setting it up to see if it expires or not.
On Mon, Dec 05, 2022 at 02:01:26PM -0800, Bence Ferdinandy wrote:
:D I really meant no pressure, I think it would be perfectly reasonable if this would not be your preferred end-of-year activity :) So I was really just interested in it if you plan to do it or not and then plan accordingly.
Already doing it, but can only get there gradually. As a first step I implemented your fake email address trick. I don't want to release it yet since I have no company/institution email account for testing However, you could download the prebuilt binary from https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/898933/a2284936a34cbd09/mailctl
Would you mind to test it?
mailctl authorize --help
explains the details.
Already doing it, but can only get there gradually.
Great! Thanks!
As a first step I implemented your fake email address trick. I don't want to release it yet since I have no company/institution email account for testing However, you could download the prebuilt binary from https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/898933/a2284936a34cbd09/mailctl
Would you mind to test it?
mailctl authorize --help
explains the details.
I tested with both gmail and MS. It works great for gmail. It's hard to tell with MS since I can't actually get to the end, but it seems that MS actually does NOT need a workaround like this, but will force you to click a "can't find account" link and then navigate to the institutional login.
On Tue, Dec 06, 2022 at 12:23:17AM -0800, Bence Ferdinandy wrote:
I tested with both gmail and MS. It works great for gmail. It's hard to tell with MS since I can't actually get to the end, but it seems that MS actually
Here is the next iteration:
https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/900053/e23ec1bbe42db49f/mailctl
This should send the tenant
field during authorization in the case of
microsoft. You need to include tenant: eltehu
for microsoft in
services.yaml. Try both redirect URI-s, the localhost one and what the
python script uses. I don't really understand the latter one.
Here is the next iteration:
https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/900053/e23ec1bbe42db49f/mailctl
Thanks!
This should send the
tenant
field during authorization in the case of microsoft. You need to includetenant: eltehu
for microsoft in services.yaml. Try both redirect URI-s, the localhost one and what the python script uses. I don't really understand the latter one.
Using the redirect from the mutt script will try to start the process with that link + start appended, so I don't think that's supposed to work. Manually editing the URL just gives a blank page, but I guess that really shouldn't do anything.
Using localhost I get the following error: localWebServer: fetchAuthRecord: Error in $: Failed reading: not a valid json value CallStack (from HasCallStack): error, called at lib/MailCtl/Authorization.hs:312:21 in mailctl-0.8.0-a035a5d33e44961bf73809265601f89af0a027a194bd4c896a2256e87cbea692:MailCtl.Authorization
And here's mailctl's STDOUT: https://0x0.st/odbv.html
Note, that I needed to navigate several pages from start: signin-option -> sign in to org -> give org domain -> and finally actually logging in.
What's the status of this? I used @ferdinandyb's client_id and client_secret with mailctl-bin-0.8.4-1 from AUR, but I'm getting this error from Microsoft:
AADSTS165000: Invalid Request: The request tokens do not match the user context. Do not copy the user context values (cookies; form fields; headers) between different requests or user sessions; always maintain the ALL of the supplied values across a complete single user flow. Failure Reasons:[Token values do not match;]
Followups at mailctl mailing list
Recently, my university (or MS) turned off password login for outlook, so I had to revisit my login issue I had earlier.
In the end - since I still can't authenticate with
mailctl
I ended up using themutt_oauth.py
script. I noticed today, that you actually list that as an inspiration, so I thought maybe if you took a look at my (working) config for themutt_oauth
script and at the non-workingmailctl
we could figure out whymailctl
is not working?Here's my mutt_oath config and here for mailctl. One difference I found was the redirect URI, but changing that to the same on as in the mutt script made MS complain that the redirect uri is not the same as is configured for the client.
Another very obvious difference is that in the mutt script I can tell it which sasl method to use, that is
oauthbearer
for gmail andxoauth2
for outlook. Indeed ofmailctl
only supportsoauthbearer
that might explain the whole issue.