OAuth2 support of "Office365" (for POP) looks broken? FIXED

Discussion of bugs in Seamonkey
Post Reply
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

OAuth2 support of "Office365" (for POP) looks broken? FIXED

Post by RDaneel »

This is with the latest (3/14/2022) Build By Bill(tm), 64-bit - I always forget whether I am supposed to only post "released" build issues here or if the BETAs are OK too - but in any case, this has NEVER worked for me... even though OAuth does work fine with both GMail and with my SMTP access to Office365.

So, I have at least figured out how to wipe the saved OAuth passwords so I can invoke the whole switch-to-OAuth2 sequence now. ;)

What I see that looks suspicious is that even with a cleaned out Password Manager store for these passwords, what is being STORED when I enter the whole set of credentials each time is NOT the qualified user name as shown in the "Server Settings"... but instead is ONLY the piece before the @.

(This is NOT what is stored for normal passwords, and it is not what is stored in the Google OAuth server setting.)

Perhaps this is connected to the ALWAYS-received response of "bad user or password" when I try to set and use OAuth2 with my Office365 POP access?
Last edited by RDaneel on March 17th, 2022, 11:32 am, edited 1 time in total.
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: OAuth2 support of "Office365" (for POP) looks broken?

Post by RDaneel »

Even more [anecdotal] evidence of this being broken in the POP server setting code... when I force the rebuilding of the SMTP OAuth credentials, it builds it with the CORRECT username info - including the fully qualified user@domain that is supposed to be there [in the Password Manager store].

BUT, the POP version of the same process still only stores the "stripped" version, with the bare "user" component and NO domain info.

Another question raised by all this is it *looks* like a single OAuth entry is supposed to serve multiple uses: IMAP, POP, and SMTP are all listed as components in the Password Manager store display - so is at least part of this bug because of this unwanted stripping of the domain from the credentials causing the lookup to fail, when if things were working correctly, the single Password Manager store entry WOULD serve for both POP and SMTP?
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: OAuth2 support of "Office365" (for POP) looks broken?

Post by RDaneel »

I am going to mark this FIXED (so to speak)! :)

After corresponding [here] with another user "davexl" over in Support that was having issues with OAuth2 and Gmail, they finally got somewhere and got *their* "Gmail using OAuth2" issue fixed - by seeing (and changing) some entries in about:config that didn't look right in that they seemed to correlate with the errors he was seeing.

Taking this as inspiration, I looked into my own about:config - and also found an odd entry that seemed to go along with the failures I was seeing (detailed in my earlier posts in this bug report).

What I saw was an entry "mail.server.server1.userName" with a value of my "unqualified" Office365 login name (just my last name, no "@" domain info)... while the properly-functioning-with-OAuth2 "mail.server.server4.userName", apparently being used in the auth process with Google's servers was my COMPLETE QUALIFIED username.

So I was brave and copied the fully qualified name (already shown in the mail.server.server1.realuserName config entry) into the "mail.server.server1.userName" config entry, set the account to OAuth2 once more, and... OAuth2 to Office365 started working!

For completeness, the Password Store now shows only the single OAuth entry - presumably being "shared" between both the POP and SMTP uses. Which makes sense, since both are "scopes" listed in the OAuth credential value.

There WAS a somewhat odd interaction when I went to save the new email server "account settings" - I was told there might be something wrong with my Junk settings for the account I had just pushed over to OAuth2 (???). Looking at the dialog, I just needed to re-enable the specific ("old") storage folder for junk on this account, so I did that.

Not sure what the moral of this whole painful story is... the behavior when trying to use OAuth2 with Office365 did act like some improper parsing was taking place on the "user" that was being passed to the Microsoft servers - but apparently this bogus parsing was the result of something that had happened sometime in the past - who knows when?

And yes, "frg" saying that the functionality should work, and that I needed to try with a fresh profile would most likely have NOT shown the bizarre behavior I was seeing... was not wrong. ](*,)
frg
Posts: 1361
Joined: December 15th, 2015, 1:20 pm

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by frg »

The real issue was a missing backport (always need to pick realUserName for oauth 2). Should be fixed in current 2.53.12b1 pre and in upcoming 2.53.11.1 (hopefully we will be able to build it this weekend).
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by RDaneel »

Not surprised, in the sense that the "real user name" field was there for something. ;)

This also "feels" better, in that I wanted there to be code that was missing (or just wrong) - it is scary when bizarre config values from who knows when (or why) can reach out and cause mysterious trouble.

I don't know if this is a case-sensitive lookup, but the config entry is "realuserName", which may be a mistake - but that is what is in my config store.

I also like that there is now a single credential entry in the Password Manager that encompasses POP, IMAP, and SMTP.

Thanks, f-r.
frg
Posts: 1361
Joined: December 15th, 2015, 1:20 pm

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by frg »

> I don't know if this is a case-sensitive lookup, but the config entry is "realuserName", which may be a mistake - but that is what is in my config store.

No typed here from memory and didn't look into the patch. It is realuserName. Someone on alt.comp.software.seamonkey tested and it is fine. Same issue came up there.

FRG
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by RDaneel »

Looking forward to the real fix, as something about my "identity" vs my local email folder structure is a bit confused - this is clearly related to the weirdness I noticed with my Junk folder I mentioned above.

My Sent stuff copies are now going to "Local Folders / Sent", for instance.

I will revert my "fix" as soon as your backport is in (change to the config setting "username" field) and set it back to its previous value - the unqualified portion of the full "real user name" entry.
frg
Posts: 1361
Joined: December 15th, 2015, 1:20 pm

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by frg »

It is in current 2.53.12b1 pre. If you see problems with it then it is something else or gremlins.
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by RDaneel »

Well, it is gremlins - but inspired and created by my workaround to the original missing backport. :(

Yes, thanks, the code is there now and seems to work as intended - I put the original "unqualified" name entry back into the userName field in my config, and realuserName is clearly being used now - my OAuth2 single entry in the Password Store is working exactly right, and is clearly shared between the POP and SMTP entries when accessing the Office365 servers.

What's "wrong" is that something, starting with my manual hacking of the "userName" field to contain the "realuserName" value, created a cascading set of mail identities being created - there are now 10 of these things.

I am referring to all the entries that look like

mail.identity.id<N>

I could probably clean all this up manually, but there are definitely things I don't know about how this all organized and used... I really wish I could figure out *which* one is considered "current". For instance, it is pretty clear that "id2" is actually active, and is the one that shows changes when I make edits in the "Mail & Newsgroups Account Settings" panel - but it is the ONLY one of the bunch that is missing a mail.identity.id<N>.valid entry (whatever that means)!

I *could* just ignore all the "zombie" entries that got created, I suppose - but as you can guess, they really bother me. Grrr.

Thanks again for getting the OAuth2 support working, as now i won't lose access through my favorite email client to my email when Microsoft finally kills off "dumb" passwords later this year. ;)
frg
Posts: 1361
Joined: December 15th, 2015, 1:20 pm

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by frg »

Check if the entries have a valid key which is true. If not they should be not valid :)

Building 2.53.11.1 is now ongoing which includes the fix.
RDaneel
Posts: 603
Joined: January 19th, 2004, 2:43 pm
Location: Puget Sound, WA
Contact:

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by RDaneel »

So, the end of the tale has some answers and some questions... basically, all the mail.identity.* config entries seem (to me) to be packing way too much "extra" settings. To me, all that I really see/use is the ability to adjust the "from" field (just selecting different tiny text files that contain sigs)... but these all have the complete set of folder paths for Drafts, Sent, Junk, etc along WITH just the "sig" selection. It does seem quite strange that the set of entries that must be getting used for my default "identity" does NOT have the "valid" flag set.

And since the way they get looked up and accessed by SM is apparently built upon the "userName" entries, when I hacked that to force the use of the realuserName *value* for the OAuth2 stuff, it broke the assumptions about naming the above-mentioned folders. :(

In the end, even restoring the userName value to its original setting was not enough to bring everything back, so my folder structure was now badly broken / inconsistent across these "identities" - and since it was really unclear what was needed to perform [enough] surgery on the config entries to fix this problem - I reverted to a backup from a little over a week ago, and then just stuffed in the various correct "mbox" files (remembering to delete the ".msf" files, of course) and re-constructed my profile somewhat painfully. :|

Anyway, all is good, no significant email lost, and OAuth2 is [still] working! ;)
User avatar
ndebord
Posts: 1122
Joined: December 7th, 2002, 9:53 am

Re: OAuth2 support of "Office365" (for POP) looks broken? FI

Post by ndebord »

Just as an aside. I too have a Hotmail account, but it will not work with OAuth2 and Microsoft. This is the error message I get. "You can't sign in here with a personal account. Use your work or school account instead."

Nick
-N- Si vis pacem, para bellum
FrameWork, SeaMonkey(64-bit),Windows 10 Pro (X64- 21H2), WinPatrol, Malwarebytes & Panda Dome
Post Reply