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

Status: RESOLVED FIXED

(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.

Comment 12

[Magnus Melin [:mkmelin] (away, back Aug 4)]

Attachment: Bug 1907115 - Don't apply message content policy for javascript: links. r=babolivier

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/b8438e3b135f
Don't apply message content policy for javascript: links. r=babolivier

Comment 14

[Magnus Melin [:mkmelin] (away, back Aug 4)]

Ryan, please try the 2025-02-14 daily and see if things now work for you.

Comment 15

[Ryan Lee Sipes]

Yes, this works!

Comment 17

[Wayne Mery (:wsmwk)]

Is this ready for 128?

Comment 18

[Magnus Melin [:mkmelin] (away, back Aug 4)]

Probably ok, but could be preferable to have the 137 release with it first.

Comment 19

[Magnus Melin [:mkmelin] (away, back Aug 4)]

Comment on attachment 9465926 [details]
Bug 1907115 - Don't apply message content policy for javascript: links. r=babolivier

Uplift Approval Request

• Please state case for uplift consideration and ensure bug severity is set: Custom OAuth2 pages may not work
• User impact if declined: May not authenticate
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Daily?: Yes
• Has the fix been verified in Beta?: Yes
• Needs manual test from QA?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): In theory not risky, but affects code that it would be bad to break.
• String changes made/needed: none

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to Magnus Melin [:mkmelin] from comment #18)

Probably ok, but could be preferable to have the 137 release with it first.

Only just went out, so still holding off for 128.

Comment 21

[Corey Bryant]

Comment on attachment 9465926 [details]
Bug 1907115 - Don't apply message content policy for javascript: links. r=babolivier

[Triage Comment]
Approved for esr128

Comment 22

[Daniel Darnell [:dandarnell]]

Thunderbird 128.9.2esr:
https://hg.mozilla.org/releases/comm-esr128/rev/3371d0f1f7b7