Similar to the other support tickets, except with Okta, I can authenticate successfully and get the 2FA response but then it redirects to a page (https://COMPANY.okta.com/app/office365/XXX/sso/wsfed/passive; where COMPANY is the company's name and XXX looks like an identifer) that says "Signing in to Microsoft Office 365" where it stalls.
At the bottom of the page is this HTML:
<SCRIPT type="text/javascript"> $(function(){ var delayInterval = 0; if (delayInterval && delayInterval > 0) { setTimeout(function() { document.getElementById('appForm').submit(); }, delayInterval); } else { document.getElementById('appForm').submit(); } }); </SCRIPT>
which apparently should trigger the HTML form to POST but I don't see any evidence in DavMail's log that it actually did. It eventually times out.
Once that initial attempt times out, the next popup window instead gives me a different page (https://COMPANY.okta.com/policy/second-factor; where COMPANY is the company name) with page title "COMPANY - Extra Verification" except the body is blank except for a background graphic, "Connecting to Office365" title at the top, and "Powered by Okta" footer. This page has HTML code like:
<!-- hidden form for reposting fromURI for X509 auth --> <FORM action="/login/cert" method="post" id="x509_login" name="x509_login" style="display:none;"> <INPUT type="hidden" class="hide" name="_xsrfToken" value="..."/> <INPUT type="hidden" id="fromURI" name="fromURI" class="hidden" value="..."/> </FORM> <DIV class="content"> <DIV class="applogin-banner"> <DIV class="applogin-background"/> <DIV class="applogin-container"> <H1> Connecting to<DIV class="applogin-app-logo"> <IMG src="https://ok4static.oktacdn.com/assets/img/logos/office365.4d711d1fe185fdc7fce851dd80cbf15d.png" alt="Microsoft Office 365" class="logo office365"/> </DIV> </H1> <P>Sign-in with your {COMPANY} account to access Microsoft Office 365</P> </DIV> </DIV>
although the "Sign-in with ..." message is not visible anywhere. Possibly that URL also needs the integrity check disabled.
If I change the test in "O365InteractiveAuthenticatorFrame.java" from:
to:
then the first page hanging goes away and I get to a page asking to accept permissions, which succeeds.
Looks like mail works fine with that change, but one of the other access methods (I'm guessing calendar) gets stuck on the page "https://login.live.com/oauth20_authorize.srf". It failing does not seem to impact the mail working, so it is less of a concern right now.
Thanks for your feedback.
Patch merged, can you please check again with latest trunk ?
I dropped my patch and updated to r3048 and it works fine for email, but calendar access still gets hung with a blank white page at the URL https://login.live.com/oauth20_authorize.srf?XXX (it query parameters are a bunch of identifiers so can't really include).
Ok this means you configured calendar with a different username: Microsoft detects a personal account and switches to oauth20_authorize mode.
=> this is fixed in latest trunk
=> however you still need to fix username
I checked and it is the same email address in the calendar URL as my Office365 account, so not sure why it would be going to a personal account. You can close this ticket for now though as the email at least works. I'll revisit the calendar later.
Last edit: George Greer 2019-06-24
Ok, closing this ticket for now, please reopen a new one if you get more info on the calendar issue.