Hi,
Sorry for the very slow reply on this, but I have a bit more info I can
provide now, and a workaround which doesn't need any modifications to
the current source code.
Run `mailctl authorize microsoft <your@company.email>` with your proper
email address, then when you visit the http://localhost:8080/start page,
instead of trying to log in straight away (which leads to the
"localWebServer - invalid request" dump), do the following:
- Click "Sign in with another account"
- Click "Sign-in options"
- Click "Sign in to an organisation"
- Put in the correct domain name which matches your company.email
address above
- Now log in as normal and this works without any file renaming or fake
email addresses :)
The final login screen has redirected to the URL
"https://login.microsoftonline.com/<domain>/oauth2/v2.0/authorize?client_id=..."
..rather than the original localhost address, but then redirects back to
the localhost address as expected.
I've tried setting the tenant to the names which I can find in our O365
company setup, with no improvement, and I've tried changing the
auth_endpoint URL in the services.yaml file, to include the domain as
above instead of "common", which also had no effect.
services.yaml contains this:
microsoft:
tenant: "<domain removed>"
auth_endpoint: "https://login.microsoftonline.com/common/oauth2/v2.0/authorize"
auth_http_method: "GET"
auth_params_mode: "query-string"
token_endpoint: "https://login.microsoftonline.com/common/oauth2/v2.0/token"
token_http_method: "POST"
token_params_mode: "request-body-form"
redirect_uri: "http://localhost:8080"
auth_scope: https://outlook.office365.com/IMAP.AccessAsUser.Allhttps://outlook.office365.com/SMTP.Send offline_access
# Thunderbird client ID and secret:
client_id: "08162f7c-0fd2-4200-a84a-f25a4db0b584"
client_secret: "TxRBilcHdC6WGBee]fs?QR:SJ8nI[g82"
I'll see if there is any useful debug output I can get to find the
differences between these authentication flows, but this is an
improvement at least :)
Cheers,
David
> Sorry for the very slow reply on this, but I have a bit more info I can> provide now, and a workaround which doesn't need any modifications to> the current source code.
This was by building from the latest git sources which label themselves
as 0.8.6, by the way.
Hi,
On Fri Apr 14, 2023 at 13:05, David Gardner wrote:
>> Hi,>> Sorry for the very slow reply on this, but I have a bit more info I can> provide now, and a workaround which doesn't need any modifications to> the current source code.>> Run `mailctl authorize microsoft <your@company.email>` with your proper> email address, then when you visit the http://localhost:8080/start page,> instead of trying to log in straight away (which leads to the> "localWebServer - invalid request" dump), do the following:>> - Click "Sign in with another account"> - Click "Sign-in options"> - Click "Sign in to an organisation"> - Put in the correct domain name which matches your company.email> address above> - Now log in as normal and this works without any file renaming or fake> email addresses :)>> The final login screen has redirected to the URL> "https://login.microsoftonline.com/<domain>/oauth2/v2.0/authorize?client_id=..."> ..rather than the original localhost address, but then redirects back to> the localhost address as expected.
nice! Indeed, I can confirm that this works for me as well with the latest main
from sr.ht.
Thanks for figuring this out!
Best,
Bence
--
+36305425054
bence.ferdinandy.com
On Fri, Apr 14, 2023 at 12:05:07PM +0100, David Gardner wrote:
> I have a bit more info I can provide now, and a workaround which> doesn't need any modifications to the current source code.>> Run `mailctl authorize microsoft <your@company.email>` with your proper> email address, then when you visit the http://localhost:8080/start page,> ...
David thank you for this! I am going to incorporate (pun intended :-) your
workaround into mailctl's documentation as part of a new minor release.
Also, happy to hear that this solves Bence's problem too.
A few questions just to avoid any misunderstanding.
> The final login screen has redirected to the URL> "https://login.microsoftonline.com/<domain>/oauth2/v2.0/authorize?client_id=..."> ..rather than the original localhost address, but then redirects back to> the localhost address as expected.
Not clear on what that exactly means. Does this redirection happen
automatically or you need to click on something?
> I've tried setting the tenant to the names which I can find in our O365> company setup, with no improvement, and I've tried changing the> ... > services.yaml contains this:> > microsoft:> tenant: "<domain removed>"
What does this "<domain removed>" stand for exactly in your final config
file? So what should I write here in the services.yaml template distributed
with mailctl?
> This was by building from the latest git sources which label themselves as> 0.8.6, by the way.
What version of ghc did you use? I know that mailctl does not compile with
ghc 9.6 at the moment. The current binary release was produced using ghc 9.4
Cheers,
Peter
Peter Dobsan <pdobsan@gmail.com> writes:
>> I have a bit more info I can provide now, and a workaround which>> doesn't need any modifications to the current source code.>>>> Run `mailctl authorize microsoft <your@company.email>` with your proper>> email address, then when you visit the http://localhost:8080/start page,>> ...>> David thank you for this! I am going to incorporate (pun intended :-) your> workaround into mailctl's documentation as part of a new minor release.
No problem and thank you for getting mailctl 99% of the way there
already! I'm glad it's working well enough that I could point other
people at it as a way of getting clients other than Outlook to work :)
> A few questions just to avoid any misunderstanding.>>> The final login screen has redirected to the URL>> "https://login.microsoftonline.com/<domain>/oauth2/v2.0/authorize?client_id=...">> ..rather than the original localhost address, but then redirects back to>> the localhost address as expected.>> Not clear on what that exactly means. Does this redirection happen> automatically or you need to click on something?
I mean that once you've put in the domain name of your organisation it
goes to that page as the login page, with the domain name you've
specified where I put "<domain>" and the redirect URL set to the
localhost:8080 page mailctl provides. The login.microsoftonline.com
oauth2 URL is the normal one seen when logging into the O365 services.
(But I don't know why the mailctl authorize workflow doesn't go straight
to this without the workaround steps I provided!)
>> I've tried setting the tenant to the names which I can find in our O365>> company setup, with no improvement, and I've tried changing the>> ... >> services.yaml contains this:>> >> microsoft:>> tenant: "<domain removed>">> What does this "<domain removed>" stand for exactly in your final config> file? So what should I write here in the services.yaml template distributed> with mailctl?
It doesn't seem to matter what is put here. I'm not sure it actually
even needs to be in the file -- I should try again without it.
I was trying various things out to see if any tenant value would match
things up properly without needing the workaround steps, and just took
out the company domain when I pasted it...
Actually, just tested again without the tenant value set at all and it
works the same way, so it can be removed from the example.
>> This was by building from the latest git sources which label themselves as>> 0.8.6, by the way.>> What version of ghc did you use? I know that mailctl does not compile with> ghc 9.6 at the moment. The current binary release was produced using ghc 9.4
ghc 9.2.5, which I guess is just whatever ghcup installed for me without
me specifying anything else :)
Hope this helps,
David
On Fri Apr 14, 2023 at 16:51, Peter Dobsan wrote:
> On Fri, Apr 14, 2023 at 12:05:07PM +0100, David Gardner wrote:> > I have a bit more info I can provide now, and a workaround which> > doesn't need any modifications to the current source code.> >> > Run `mailctl authorize microsoft <your@company.email>` with your proper> > email address, then when you visit the http://localhost:8080/start page,> > ...>> David thank you for this! I am going to incorporate (pun intended :-) your> workaround into mailctl's documentation as part of a new minor release.> Also, happy to hear that this solves Bence's problem too.>> A few questions just to avoid any misunderstanding.>> > The final login screen has redirected to the URL> > "https://login.microsoftonline.com/<domain>/oauth2/v2.0/authorize?client_id=..."> > ..rather than the original localhost address, but then redirects back to> > the localhost address as expected.>> Not clear on what that exactly means. Does this redirection happen> automatically or you need to click on something?
I didn't need to do anything.
>> > I've tried setting the tenant to the names which I can find in our O365> > company setup, with no improvement, and I've tried changing the> > ... > > services.yaml contains this:> > > > microsoft:> > tenant: "<domain removed>"
As a reference, this is my current MS config, the tenant is the subdomain
before .sharepoint.com.
https://github.com/ferdinandyb/dotfiles/blob/691a5ea6954be67e1f5c5df3fc3bea4b26379fd0/.config/mailctl/services.yaml#L13
Hmm, I just tested with the tenant commented out. It would be nice if David
could confirm, but it seems it is not needed at all? At least not with this workaround.
Best,
Bence
--
+36305425054
bence.ferdinandy.com