Open Bug 1668834 Opened 4 years ago Updated 1 year ago

O365 OAuth2 authentication 1st verifyLogon sometimes doesn't work, 2nd time it works

Categories

(Thunderbird :: Security, defect)

defect

Tracking

(Not tracked)

People

(Reporter: mkmelin, Unassigned)

References

Details

(Whiteboard: [STR: comment 1])

+++ This bug was initially created as a clone of Bug #1528136 +++

This bug is to track the initial O365 verifyLogon failure when using OAuth2 in the account wizard.
It's only reproducible sometimes and possible it's a server bug. Usually if I set up one account, after that it's no longer reproducible in a clean profile.

STR:

  • set up office 365 account in the account wizard
  • choose manual config, and then OAUth2 for authentication
  • click Verify

You'll see a "something wrong with the configuration" message.
Clicking Verify again, it will succeed.

Just to clarify the STR:

  1. Bring up dialog to start a new account.
  2. Enter name, email address and password.
  3. Click "Continue" (Don't click "manually" here I assume).
  4. Now click "manually".
  5. Change authentication from normal password to oauth2 for both in- and out-going.
  6. Click "retest". Worked for me! I see no error. I see a green checkmark and "The following setting were found probing the server"
  7. Click "done". A screen pops up asking for the password

Is this the correct STR? If I click "manually" at step 3 you have to fix the server names which default to the email address.

I'll continue on and see what happens.

I continued on and entered my password on the screen. I choose something about allowing access for 14 days. When I submitted it, tb came back to the original account creation page with a yellow banner saying approx:

Configuration could not be verified. Password or username may be bad. Try another protocol or account. Etc.

I clicked "Re-test" again. The message went away. Now clicking "Done"

Now I see the new account with just an Inbox and Trash.

Yeah, you just saw the bug in action then. Obviously it should just go through directly instead of having to re-try the (claimed to be non-working) configuration once more. I.e. the "Configuration could not be verified. "... etc should not happen.

Type: enhancement → defect

Is server still the likely cause?
Is it still reproducible?

Flags: needinfo?(mkmelin+mozilla)
Severity: normal → S3
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(mkmelin+mozilla)

Does anyone have examples from support, or information to add to comment 1 about how to reproduce this or the possible cause?

I didn't find obvious examples in these bug queries https://mzl.la/3Hkfjyi)or https://mzl.la/3DqrCId but perhaps someone else could check.

Flags: needinfo?(mkmelin+mozilla)
Whiteboard: [STR: comment 1]
You need to log in before you can comment on or make changes to this bug.