Use OAuth client id with a https (secure) redirect url #494
Comments
|
Sorry for the delay. Does the error displays straight, or after a delay? Do you have time to click on the link? I tried recently and the Outlook flow worked as expected for me. I will give another shot in the nearest day and let you know. |
|
Oh wait I just noticed the redirect scheme with |
Those are shell commands to retrieve the access token or the refresh token. So |
Yes. I've dug into this explanation by reading the code that manages the oauth flow. In oauth/src/v2_0/authorization_code_grant.rs it's also actually hardcoded the http scheme. |
Good to know. I retryed this approach without success. Trace of this try: |
|
Great, we are going forward now. I see in the logs that it uses keyring for the client secret. I don't know how you put your client secret with backend.auth.client-secret.cmd = "shell-command-that-retrieves-secret"
# or using raw, not safe and not recommended (yet useful for testing purpose)
backend.auth.client-secret.raw = "S€cяэT" |
|
With About Himalaya: I first tried to configure the account without reusing pizauth; the interactive UI asked for client secret and I think that I just sent a blank line or I pasted a old client secret of Thunderbird (which was paired with a different client id). --
Every attempts failed with the same trace of my last message. Also I add that the connection attempt blocks for a minute ( |
Looks like I miss some piece of information there. I thought the client secret was mandatory. The code expects a client secret as well. So either Thunderbird has a special authority that I'm not aware of, or the flow should accept not to have a client secret. I will investigate and let you. |
|
Is your client id Can you tell me a bit more how you configured your Thunderbird and pizauth? Is it for a personal account (like personal outlook account) or for a company? |
Yes, that is the client id of Thunderbird (the desktop version) that I'm using.
Yes, with Outlook the client id must be "authorized" by the organization. My organization has authorized Thunderbird.
Thunderbird is not running on my machine.
For work accounts (two, one is issued by my gov), so company. |
Apparently that is the case. I quote from pizauth readme:
Emphasis mine. |
|
Interesting. I can try to make the client secret optional and see if it works for you. I let you know. |
|
I made the client secret optional, could you try again with a pre-built binary? |
|
Hi, the pre-built binary miss the oauth2 feature so I tried to rebuild from git locally (I'm running cargo 1.81.0). With same account/config (I only changed the name) I think this fails nevertheless with some kind of bootloop (while trying to fetch inbox contents?), trace: Screencast: By the way the process continued to run until this very moment (so for 7 minutes) before being apparently killed by my OS (I think, the terminal program simply disappeared). P.S. I'm on a GNU/Linux system (openSUSE Tumbleweed). |
|
I'm getting the same stuck issue with a public application too. I've realised how to create public (no secret) applications: Basically when you create the authentication/platform configuration URL in the image below, if you choose (3) then you create a confidential application which needs a secret, and if you choose (4) then you don't need a secret
So this might make the issue more easy to reproduce? And with this knowledge, I've managed to fetch my mail by converting my public app to a confidential app |
Yes indeed, I forgot this detail.
In fact it cannot connect to the TLS stream, we see on the screencast that it hangs for a while before looping. I justed push a fix that prevents the loop: you can pull and try again, you should get sth similar to #494 (comment): This error comes from the initial TCP connection to the server: let tcp_stream = TcpStream::connect((host.as_str(), port))
.await
.map_err(ClientError::ConnectTcp)?;Which means that it fails connecting to the host via the given port. Do you confirm that a simple backend.port = 143
backend.encryption = "start-tls"I cannot reproduce the issue with my personal Outlook account, both TLS and STARTTLS work. Not sure how to help you. |
|
If it was an auth issue, we would get TLS logs, and the error would look like in #501. |
I can confirm, now it outputs this:
Telnet seems to be able to connect:
Just tried, it fails:
Could there be some error in my configuration? I only configured himalaya by reading the example in the readme and the sample in the repo. |
|
This looks way better, we see now TLS negociation. @duesee any idea why the server just sends |
|
Two observations: First, after STARTTLS, the server doesn't send a second But I'm not sure about our STARTTLS handling state right now. Did you already change it as discussed to use the streamlined approach w/o parsing? A caveat I missed when we talked last time was that after STARTTLS the connection must not expect a second greeting. This is easy to solve with a See duesee/imap-next#294. |
The Himalaya suite actually uses this version of
Looks like something is wrong is the STARTTLS algorithm, let me check back. |
|
@sevalsixarci I was able to reproduce and to identify what is missing (see duesee/imap-next#296). Now I have another error, somehow it cannot Once the PR is merged, I will close this issue in favor of #501 (duplicate). |
|
I just pushed a fix meanwhile, could you try again? |
|
Hi, now himalaya works. I see the content of my mailbox. Do you need traces or other test? |
|
No it's fine, in fact the issue comes from Microsoft. It looks like it's not possible anymore to login to personnal account with plain auth (OAuth is now required). I also tried with OAuth and it works as expected. Thank you for your patience 🙏 |
|
I thank you as well for your patience, clarity and kindness. (: |
|
To recap quickly: It was OAuth from the beginning and we found the STARTTLS bug accidentally, right? Then I would recommend to you @sevalsixarci to use "implicit TLS" (imaps on port 993) again to get a more secure and faster connection :-) |
|
It was OAuth from the begining but the TCP connection on port 993 was kind of timing out? Then STARTTLS helped to go forward till the bug we discovered. BTW, @sevalsixarci could you try again TLS on port 993? |
Umh… it fails: So STARTTLS on port 143 works but the preferred conf with port 993 don't. |
|
Really strange. I cannot reproduce the error, my personal account works both using TLS 993 and STARTTLS 143. Your logs really show that it does not even reach the server, it fails before even TLS negociation. Must be a Microsoft mis-configuration issue from your side? At least the STARTTLS variant works for you. What a pain… |
Dunno. This is my config: |
|
I mean it can. My account is not personal (I deprecate M$ things, from UX and politics POV), is a work account. Maybe the management has enabled some subtle different behavior bout TLS for the sake of "security"; I mean they refuse to let me send mail outside the Outlook UI because they are not able to read how to authorize Thunderbird (so I read only and don't answer, I refuse) . Any way, rant aside (I apologize), it seems that TLS negotiation still fails, but -- |
|
Does a simple .... ... show you the IMAP greeting? |
Yes, after the handshake: But the account that with himalaya wont connect using TLS 993 does connect with different stack (my current setup rests on mbsync). |
Hi,
I'm exploring the project to replicate my current email setup which use mu, mbsync, msmtp, and pizauth (OAuth token fetcher/daemon). I compiled himalaya from git with OAuth2 and keyring features enabled (the repository's head at the time of compilation was commit
92814d6).The issue is that I can read mail from account using standard IMAP, but OAuth authentication fails for my Outlook work accounts. Since I am authenticating as Thunderbird (authorized with HTTPS redirects on localhost), attempting to fetch mail gives the following error:
Config snippet:
I also tried to bypass this by reusing the OAuth tokens from pizauth, with these config lines (but I think I may have misunderstood some of the config keys):
Some logs:
The text was updated successfully, but these errors were encountered: