1907115 - Two Factor OAuth (for text and email) not working - Office365

Status: ASSIGNED

(Thunderbird :: Account Manager, defect)

Description

[Ryan Lee Sipes]

Attempted to set up an O365 account, associated with a university. I was not able to use the two-factor auth for text message two-factor, but was able to do the two-factor via the Security Question.

When attempting to load the two-factor page for the text, the page simply was a gray page with no elements on it. This was repeatable, tried a number of times.

Happy to test to figure out what's going on, but need some guidance on where to get helpful information.

Comment 1

[Anje]

outlook office365 using Authentication Method : Oauth2 for incoming and smtp
In Settings > Privacy & Security - web content - select 'accept cookies from sites'
When microsoft prompts in browser window for password it uses localhost and window may appear blank if it cannot do this.
Do you have anything using the localhost ? eg: Apache - if yes, switch it off whilst setting up oauth

If using 2 step verification and an app specific password then you have to use Authentication Method: Normal Password.
To use Oauth you need to switch off 2 step verification.
Did any of this info help?

Comment 2

[Brendan Abolivier [:babolivier]]

Does the same thing happens when trying to access the Outlook web app? If you're already logged into this account in your browser, make sure to log out so you go through the authentication process there too.

I don't think we do 2FA from within Thunderbird, besides the OAuth2 dialogs, which only display the provider's portal (until it eventually returns with a token we can use). So if that's where you're seeing the failure occur, it sounds to me like it's happening within Microsoft's authentication portal and not code we maintain, unless you're hitting some undefined edge case in the OAuth2 code (which isn't impossible).

Comment 3

[Ryan Lee Sipes]

I do not see the same issue via the web app. It's only for Thunderbird and only on text and email 2FA (which happens in the little pop-up window for OAuth). Happy to hop on a short Zoom call and walk you through it so you can see it in action.

Comment 4

[Wayne Mery (:wsmwk)]

Ryan, still seeing this?

Comment 5

[Brendan Abolivier [:babolivier]]

We paired on this a bit in Dublin, it's still a thing but requires some bandwidth from either Sean or me to take a deeper look.

Comment 6

[Brendan Abolivier [:babolivier]]

(reinstating my NI request which I accidentally cleared)

Comment 7

[Ryan Lee Sipes]

Coming back to share that I'm happy to provide further info and can maybe even get a test account to use for those working on it.

Comment 8

[Brendan Abolivier [:babolivier]]

I finally found some time to look into this with Ryan's test credentials. My findings are the following:

• Upon clicking the button to send a 2FA text, the content process for the OAuth pop-out webview crashes
• The href of that button's link refers to the URL javascript:void(0);
• Clicking it calls our content policy code: nsMsgContentPolicy::SetDisableItemsOnMailNewsUrlDocshells (via nsMsgContentPolicy::ShouldLoad)
• This happens in the content process - previous calls to nsMsgContentPolicy::ShouldLoad in this context seem to happen in the parent process
• The content policy code allows this URL to load, and attempts to set BrowsingContext::SetAllowJavascript(true) on the target's browsing context (which Gecko supply as part of a nsILoadInfo object)
• The browsing context sees that we're using Fission, and that we're in the parent process, and denies the change
• The function for committing the change (to AllowJavascript) catches this denial and calls MOZ_CRASH

I'm not entirely sure why this is happening. At a glance, it looks like there's a mismatch in the expectations of Gecko and Thunderbird: Gecko seems to expect that we can only change the browsing context's AllowJavascript from the parent process, but we seem to expect we should be able to set it from any process, or that it will never be called in the content process. At a glance I would say Gecko is probably right; nsMsgContentPolicy::ShouldLoad doesn't look like the kind of function that should make changes to the browsing context. But I don't have enough familiarity with our content policy, or Gecko's handling of content policies and browsing contexts, to be confident I have a good enough picture to state on how to fix this.

It looks like this situation has been around for years (both the restriction on using the parent process to set AllowJavascript, and nsMsgContentPolicy setting it, possibly in the content process), so given the lack of previous reports on this issue (and you mentioned a workaround) I don't think it needs fixing urgently. Needless to say, this kind of issue will go away if/when we decide to start using the browser to run web authentication flows.

Comment 9

[Ryan Lee Sipes]

Unfortunately, the policy on the account I'm testing with changed to remove the workaround for 2FA. What is the blocker for using the browser for web authentication flows?

Comment 10

[Brendan Abolivier [:babolivier]]

Currently we get the token at the end of the auth flow by detecting the redirects and catching the one that contains the token (extract it from there). We can do this because we control the window in which the flow runs.

This is not the case if we use the browser for auth flows. In order to do this, we'll need to be able to run a local web server within Thunderbird, capable of handling local requests resulting from the auth flow redirecting the user's browser to it (with the token to use as a query parameter). It's certainly doable, but not a quick fix.

I'll keep looking at possible ways to address this bug.

Comment 11

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1907115 - Don't try to set BrowsingContext::SetAllowJavascript outside of the parent process. r=#thunderbird-back-end-reviewers

It seems like sometimes nsMsgContentPolicy::ShouldLoad might be called from a
content process. When the request is for a document, we try to set
AllowJavascript on the browsing context. However this is only possible from
the parent process. Trying to set it on a different process makes said process
crash entirely.

This patch prevents this crash by checking which process we're on before
attempting to call SetAllowJavascript.