-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot connect with O365Manual (or any other setting) #330
Comments
If you are on windows please have a look at the WebView2 based authentication script at https://github.com/mguessan/o365psauth This script is based on Microsoft provided WebView2 browser implementation, the one used in Edge Chromium and all other "new" Microsoft clients (New Outlook, New Teams, ...) |
Thanks for taking a look at the issue, much appreciated! Unfortunately I'm on Linux. Is there a Linux variant of the required dlls? |
If your company enforces device level authentication there is no way to authenticate on a non registered device. What happens if you access: on a company provided laptop? |
The link works and it forwards me to my companies login page. After successful login (partial), it asks for the 2FA. After providing the code, a new window pops up asking me whether I try to sign into Microsoft Office. If I click continue, funky stuff happens. On Firefox, it just keeps cycling back to the website, in an infinite loop. On Chromium, it asks me whether I want to open xdg-open. If I say yes, it produces a Chromium generated error message subjected "Failed to open URI". Same behavior if I click on cancel instead of continue. Edit: I don't have a company provided device. Edit2: Might also be interesting, I can log into the online version of MS Outlook from my own device just fine, it's just the forwarding to anything else that doesn't work. |
Interesting, the xdg-open is because Chrome detects an unsupported protocol (urn:) The interesting part is the last redirect after you click last button to confirm |
This comment was marked as outdated.
This comment was marked as outdated.
Copy the 'urn:ietf...' string (all except the wrapping quotes) back to the DavMail pop-up that initiated this. What you're seeing is that your browser doesn't know what to do with the URI scheme 'urn:ietf...', which contains the auth token that DavMail is waiting to complete the authentication, so, just copy-paste it from the Js console. It has always worked like that for me. |
Just gave that a try, putting the entire string within the wrapping quotes into the Office 365 - Manual authentication window of DavMail. However, it keeps asking again and again, and later on asks me to open a browser (through which I can log in) Doesn't connect unfortunately. Edit: Also tried copying the code only part from within the quotes (without session information), but that didn't work either |
I'm sorry to read that, it works for me. Check the DavMail logs after you send the code, to see if they suggest some other problem. |
@VoodooCode14 please be aware that the code has a very short lifetime. Also please don't post it in cleartext as it's sensitive information. The code must be exchanged through a POST request to microsoft token endpoint for an actual token in json format. |
Hi,
until early 2023, I have been able to use davmail to connect properly to an outlook server. However, my organization decided to increase security, now I cannot get davmail to work anymore (unfortunately). I noticed that I'm not getting a token anymore during the forwarding process. I can still see the client_id and redirect_url, however, there is a new field called protectedtoken which is set to true, followed by a claims field described below:
afterwards, there is a final field called nonce which contains a very long string (potentially related to the token?).
Would appreciate any feedback on whether davmail currently supports this format and/or whether I can configure it to support it.
The text was updated successfully, but these errors were encountered: