Bug 1528136 Comment 119 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Re bug 4 in my last comment:

Reproduction:
Steps:
1. Code: TB trunk, plus the backed out patch re-applied, plus a fix for point 2 above.
2. Create a new TB profile and start the account creation dialog
3. Enter email address with IMAP and MFA (type 2 above), enter password
4. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB
5. The window closes, but the login fails (that's the bug 4).
6. Consequently, (o) Exchange is selected as default protocol. (That's a consequence of the OAuth2 process failing, not of the backed out patch.)
7. Manually change back to (o) IMAP
8. Click [Done]
9. OAuth2 works now, without webpage, because the user is already logged in.
10. The account is set up correctly.
So far, it looks like the backed out patch is at fault. But now it gets interesting:
11. Delete the profile and create a completely new TB profile.
12. Enter email address with IMAP and MFA (type 2 above), enter password
13. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB.
14. The window closes, but the login succeeds (compare with step 5).
15. Consequently, (o) IMAP is selected as default protocol.
16. Click [Done]
17. OAuth2 works now, without webpage, because the user is already logged in.

So, we do the exact same thing twice, in new profiles each, and the first time it fails and the second time it works.
Now, wait 1 hour or so (I haven't measured). Then, repeat steps 1.-17. You will see that it fails again the first time and it work the second time. I can reproduce this fairly consistently, with several different Office365 accounts on different domains.

Here's a possible explanation. It's a theory at this point, but an educated guess based on our development experience with Office365 login:
Tokens:
1. OAuth2 uses auth token and refresh token.
1.1. This explains the difference between Steps 4 and 9. We call `verifyConfig()` in both cases, but the second login already is authenticated, so the second login uses a different code path where we're already logged in, and that works.
2. Additionally, there's an auth code in the URL at the end of the webpage sequence. We might need to get that out and pass it to OAuth2 server. None of this is standardized, but it was needed in our case.
2.1. This might fix the failure in Step 5 == Bug 4.
2.2. This might also fix Bug 5.
3. Additionally, Microsoft uses cookies to store the login.
4. Additionally, Microsoft appears to remember the IP address *and* time.
4.1. This explains the difference between Steps 5. and 14.
4.2. Obviously, we cannot rely on that, so see Token 2.1.
Re bug 4 in my last comment:

Reproduction:
Steps:
1. Code: TB trunk, plus the backed out patch re-applied, plus a fix for point 2 above.
2. Create a new TB profile and start the account creation dialog
3. Enter email address with IMAP and MFA (type 2 above), enter password
4. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB
5. The window closes, but the login fails (that's the bug 4).
6. Consequently, (o) Exchange is selected as default protocol. (That's a consequence of the OAuth2 process failing, not of the backed out patch.)
7. Manually change back to (o) IMAP
8. Click [Done]
9. OAuth2 works now, without webpage, because the user is already logged in.
10. The account is set up correctly.
So far, it looks like the backed out patch is at fault. But now it gets interesting:
11. Delete the profile and create a completely new TB profile.
12. Enter email address with IMAP and MFA (type 2 above), enter password
13. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB.
14. The window closes, but the login succeeds (compare with step 5).
15. Consequently, (o) IMAP is selected as default protocol.
16. Click [Done]
17. OAuth2 works now, without webpage, because the user is already logged in.

So, we do the exact same thing twice, in new profiles each, and the first time it fails and the second time it works.
Now, wait 1 hour or so (I haven't measured). Then, repeat steps 1.-17. You will see that it fails again the first time and it work the second time. I can reproduce this fairly consistently, with several different Office365 accounts on different domains.

Here's a possible explanation. It's a theory at this point, but an educated guess based on our development experience with Office365 login:
Tokens:
1. OAuth2 uses auth token and refresh token.
1.1. This explains the difference between Steps 4 and 9. We call `verifyConfig()` in both cases, but the second login already is authenticated, so the second login uses a different code path where we're already logged in, and that works.
2. Additionally, there's an auth code in the URL at the end of the webpage sequence. We might need to get that out and pass it to OAuth2 server. None of this is standardized, but it was needed in our case.
2.1. This might fix the failure in Step 5 == Bug 4.
2.2. This might also fix Bug 5.
3. Additionally, Microsoft uses cookies to store the login.
4. Additionally, Microsoft appears to remember the combination of IP address and time. If the same request comes in again from a known IP address within a given time, even without any cookies, it gets different results than a completely cold request.
4.1. This explains the difference between Steps 5. and 14.
4.2. Obviously, we cannot rely on that, so see Token 2.1.
Re bug 4 in my last comment:

Reproduction:
Steps:
1. Code: TB trunk, plus the backed out patch re-applied, plus a fix for point 2 above.
2. Create a new TB profile and start the account creation dialog
3. Enter email address with IMAP and MFA (type 2 above), enter password
4. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB
5. The window closes, but the login fails (that's the bug 4).
6. Consequently, (o) Exchange is selected as default protocol. (That's a consequence of the OAuth2 process failing, not of the backed out patch.)
7. Manually change back to (o) IMAP
8. Click [Done]
9. OAuth2 works now, without webpage, because the user is already logged in.
10. The account is set up correctly.
So far, it looks like the backed out patch is at fault. But now it gets interesting:
11. Delete the profile and create a completely new TB profile.
12. Enter email address with IMAP and MFA (type 2 above), enter password
13. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB.
14. The window closes, but the login succeeds (compare with step 5).
15. Consequently, (o) IMAP is selected as default protocol.
16. Click [Done]
17. OAuth2 works now, without webpage, because the user is already logged in.

So, we do the exact same thing twice, in new profiles each, and the first time it fails and the second time it works.
Now, wait 1 hour or so (I haven't measured). Then, repeat steps 1.-17. You will see that it fails again the first time and it work the second time. I can reproduce this fairly consistently, with several different Office365 accounts on different domains.

Here's a possible explanation. It's a theory at this point, but an educated guess based on our development experience with Office365 login:
Tokens:
1. OAuth2 uses auth token and refresh token.
1.1. This explains the difference between Steps 4 and 9. We call `verifyConfig()` in both cases, but the second login already is authenticated, so the second login uses a different code path where we're already logged in, and that works.
2. Additionally, there's an auth code (not auth token) in the URL at the end of the webpage sequence. We might need to get that out and pass it to OAuth2 server. None of this is standardized, but it was needed in our case.
2.1. This might fix the failure in Step 5 == Bug 4.
2.2. This might also fix Bug 5.
3. Additionally, Microsoft uses cookies to store the login.
4. Additionally, Microsoft appears to remember the combination of IP address and time. If the same request comes in again from a known IP address within a given time, even without any cookies, it gets different results than a completely cold request.
4.1. This explains the difference between Steps 5. and 14.
4.2. Obviously, we cannot rely on that, so see Token 2.1.
Re bug 4 in my last comment:

Reproduction:
Steps:
1. Code: TB trunk, plus the backed out patch re-applied, plus a fix for point 2 above.
2. Create a new TB profile and start the account creation dialog
3. Enter email address with IMAP and MFA (type 2 above), enter password
4. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB
5. The window closes, but the login fails (that's the bug 4).
6. Consequently, (o) Exchange is selected as default protocol. (That's a consequence of the OAuth2 process failing, not of the backed out patch.)
7. Manually change back to (o) IMAP
8. Click [Done]
9. OAuth2 works now, without webpage, because the user is already logged in.
10. The account is set up correctly.
So far, it looks like the backed out patch is at fault. But now it gets interesting:
11. Delete the profile and create a completely new TB profile.
12. Enter email address with IMAP and MFA (type 2 above), enter password
13. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB.
14. The window closes, but the login succeeds (compare with step 5).
15. Consequently, (o) IMAP is selected as default protocol.
16. Click [Done]
17. OAuth2 works now, without webpage, because the user is already logged in.

So, we do the **exact same thing twice, in new profiles each, and the first time it fails and the second time it works**.
Now, wait 1 hour or so (I haven't measured). Then, repeat steps 1.-17. You will see that it fails again the first time and it work the second time. I can reproduce this fairly consistently, with several different Office365 accounts on different domains.

Here's a possible explanation. It's a theory at this point, but an educated guess based on our development experience with Office365 login:
Tokens:
1. OAuth2 uses auth token and refresh token.
1.1. This explains the difference between Steps 4 and 9. We call `verifyConfig()` in both cases, but the second login already is authenticated, so the second login uses a different code path where we're already logged in, and that works.
2. Additionally, there's an auth code (not auth token) in the URL at the end of the webpage sequence. We might need to get that out and pass it to OAuth2 server. None of this is standardized, but it was needed in our case.
2.1. This might fix the failure in Step 5 == Bug 4.
2.2. This might also fix Bug 5.
3. Additionally, Microsoft uses cookies to store the login.
4. Additionally, Microsoft appears to remember the combination of IP address and time. If the same request comes in again from a known IP address within a given time, even without any cookies, it gets different results than a completely cold request.
4.1. This explains the difference between Steps 5. and 14.
4.2. Obviously, we cannot rely on that, so see Token 2.1.
Re bug 4 in my last comment:

Reproduction:
Steps:
1. Code: TB trunk, plus the backed out patch re-applied, plus a fix for point 2 above.
2. Create a new TB profile and start the account creation dialog
3. Enter email address with IMAP and MFA (type 2 above), enter password
4. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB
5. The window closes, but the login fails (that's the bug 4).
6. Consequently, (o) Exchange is selected as default protocol. (That's a consequence of the OAuth2 process failing, not of the backed out patch.)
7. Manually change back to (o) IMAP
8. Click [Done]
9. OAuth2 works now, without webpage, because the user is already logged in.
10. The account is set up correctly.
So far, it looks like the backed out patch is at fault. But now it gets interesting:
11. Delete the profile and create a completely new TB profile.
12. Enter email address with IMAP and MFA (type 2 above), enter password
13. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB.
14. The window closes, but the login succeeds (compare with step 5).
15. Consequently, (o) IMAP is selected as default protocol.
16. Click [Done]
17. OAuth2 works now, without webpage, because the user is already logged in.

So, we do the exact same thing twice, in new profiles each, and the first time it fails and the second time it works.
Now, wait 1 hour or so (I haven't measured). Then, repeat steps 1.-17. You will see that it fails again the first time and it work the second time. I can reproduce this fairly consistently, with several different Office365 accounts on different domains.

Here's a possible explanation. It's a theory at this point, but an educated guess based on our development experience with Office365 login:
Tokens:
1. OAuth2 uses auth token and refresh token.
1.1. This explains the difference between Steps 4 and 9. We call `verifyConfig()` in both cases, but the second login already is authenticated, so the second login uses a different code path where we're already logged in, and that works.
2. Additionally, there's an auth code (not auth token) in the URL at the end of the webpage sequence. We might need to get that out and pass it to OAuth2 server. None of this is standardized, but it was needed in our case.
2.1. This might fix the failure in Step 5 == Bug 4.
2.2. This might also fix Bug 5.
3. Additionally, Microsoft uses cookies to store the login.
4. Additionally, Microsoft appears to remember the combination of IP address and time. If the same request comes in again from a known IP address within a given time, even without any cookies, it gets different results than a completely cold request.
4.1. This explains the difference between Steps 5. and 14.
4.2. Obviously, we cannot rely on that, so see Token 2.1.
Re bug 4 in my last comment:

Reproduction:
Steps:
1. Code: TB trunk, plus the backed out patch re-applied, plus a fix for point 2 above.
2. Create a new TB profile and start the account creation dialog
3. Enter email address with IMAP and MFA (type 2 above), enter password
4. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB
5. The window closes, but the login fails (that's the bug 4).
6. Consequently, (o) Exchange is selected as default protocol. (That's a consequence of the OAuth2 process failing, not the fault of the backed out patch.)
7. Manually change back to (o) IMAP
8. Click [Done]
9. OAuth2 works now, without webpage, because the user is already logged in.
10. The account is set up correctly.
So far, it looks like the backed out patch is at fault. But now it gets interesting:
11. Delete the profile and create a completely new TB profile.
12. Enter email address with IMAP and MFA (type 2 above), enter password
13. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB.
14. The window closes, but the login succeeds (compare with step 5).
15. Consequently, (o) IMAP is selected as default protocol.
16. Click [Done]
17. OAuth2 works now, without webpage, because the user is already logged in.

So, we do the exact same thing twice, in new profiles each, and the first time it fails and the second time it works.
Now, wait 1 hour or so (I haven't measured). Then, repeat steps 1.-17. You will see that it fails again the first time and it work the second time. I can reproduce this fairly consistently, with several different Office365 accounts on different domains.

Here's a possible explanation. It's a theory at this point, but an educated guess based on our development experience with Office365 login:
Tokens:
1. OAuth2 uses auth token and refresh token.
1.1. This explains the difference between Steps 4 and 9. We call `verifyConfig()` in both cases, but the second login already is authenticated, so the second login uses a different code path where we're already logged in, and that works.
2. Additionally, there's an auth code (not auth token) in the URL at the end of the webpage sequence. We might need to get that out and pass it to OAuth2 server. None of this is standardized, but it was needed in our case.
2.1. This might fix the failure in Step 5 == Bug 4.
2.2. This might also fix Bug 5.
3. Additionally, Microsoft uses cookies to store the login.
4. Additionally, Microsoft appears to remember the combination of IP address and time. If the same request comes in again from a known IP address within a given time, even without any cookies, it gets different results than a completely cold request.
4.1. This explains the difference between Steps 5. and 14.
4.2. Obviously, we cannot rely on that, so see Token 2.1.
Re bug 4 in my last comment:

Reproduction:
Steps:
1. Code: TB trunk, plus the backed out patch re-applied, plus a fix for point 2 above.
2. Create a new TB profile and start the account creation dialog
3. Enter email address with IMAP and MFA (type 2 above), enter password
4. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB
5. The window closes, but the login fails (that's the bug 4).
6. Consequently, (o) Exchange is selected as default protocol. (That's a consequence of the OAuth2 process failing, not the fault of the backed out patch.)
7. Manually change back to (o) IMAP
8. Click [Done]
9. OAuth2 works now, without webpage, because the user is already logged in.
10. The account is set up correctly.
So far, it looks like the backed out patch is at fault. But now it gets interesting:
11. Delete the profile and create a completely new TB profile.
12. Enter email address with IMAP and MFA (type 2 above), enter password
13. Webpage popup with Office365 login. Enter password and MFA code, and confirm access for TB.
14. The window closes, but the login succeeds (compare with step 5).
15. Consequently, (o) IMAP is selected as default protocol.
16. Click [Done]
17. OAuth2 works now, without webpage, because the user is already logged in.

So, we do the exact same thing twice, in new profiles each, and the first time it fails and the second time it works.
Now, wait 1 hour or so (I haven't measured). Then, repeat steps 1.-17. You will see that it fails again the first time and it work the second time. I can reproduce this fairly consistently, with several different Office365 accounts on different domains.

Here's a possible explanation. It's a theory at this point, but an educated guess based on our development experience with Office365 login:
Tokens:
1. OAuth2 uses access token and refresh token.
1.1. This (or Token 3 below) explains the difference between Steps 4 and 9. We call `verifyConfig()` in both cases, but the second login already is authenticated, so the second login uses a different code path where we're already logged in, and that works.
2. Additionally, there's an auth code (not OAuth2 access token) in the URL at the end of the webpage sequence. We might need to get that out and pass it to OAuth2 server. None of this is standardized, but it was needed in our case.
2.1. This might fix the failure in Step 5 == Bug 4.
2.2. This might also fix Bug 5.
3. Additionally, Microsoft uses cookies to store the login.
4. Additionally, Microsoft appears to remember the combination of IP address and time. If the same request comes in again from a known IP address within a given time, even without any cookies, it gets different results than a completely cold request.
4.1. This explains the difference between Steps 5. and 14.
4.2. Obviously, we cannot rely on that, so see Token 2.1.

Back to Bug 1528136 Comment 119