1174797 - handle OAuth not working with cookies/javascript disabled

Status: ASSIGNED

(MailNews Core :: Networking: IMAP, defect)

Description

[Kent James (:rkent)]

See  for example: http://mxr.mozilla.org/comm-central/source/calendar/providers/gdata/modules/gdataSession.jsm#181

Comment 1

[Wayne Mery (:wsmwk)]

I think you want tracking esr

Comment 2

[Kent James (:rkent)]

Right.

Comment 3

[Magnus Melin [:mkmelin]]

Context: if you disabled cookies, trying to do OAuth2 authentication for gmail will show a "Oops! Your browser seems to have cookies disabled. Make sure cookies are enabled or try opening a new browser window. [?] " message in the OAuth dialog. 

I'm not so sure it's ok to add it silently though, as that lets google track you elsewhere (to a limited extent) - which is probably one of the reasons you disabled cookies in the first place.

Comment 4

[aleth [:aleth]]

(In reply to Magnus Melin from comment #3)
> Context: if you disabled cookies, trying to do OAuth2 authentication for
> gmail will show a "Oops! Your browser seems to have cookies disabled. Make
> sure cookies are enabled or try opening a new browser window. [?] " message
> in the OAuth dialog. 

Also, even if cookies are enabled, if you have two different google oauth accounts, there may be conflicts (at least this has happened for twitter). For twitter, the cookies are removed once oauth is complete, cf. https://dxr.mozilla.org/comm-central/source/chat/protocols/twitter/twitter.js#866.

> I'm not so sure it's ok to add it silently though, as that lets google track
> you elsewhere (to a limited extent) - which is probably one of the reasons
> you disabled cookies in the first place.

Cleaning up the cookies on completion would also help with that issue.

Comment 5

[.m]

i would prefer sticking to imap only or making oauth opt-in. i have disabled google 2-factor-authentication for a reason. Adding a cookie exception for gmail seems to be violating privacy by design principles.

Comment 6

[Matt]

How about we offer to enable the cookies for gmail instead of just telling the user they need to. That meets both requirements for user choice and good user experience.

Comment 9

[Wayne Mery (:wsmwk)]

related bugs https://mzl.la/3nXgckB

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to Matt from comment #6)

How about we offer to enable the cookies for gmail instead of just telling the user they need to. That meets both requirements for user choice and good user experience.

Comment 14

[Wayne Mery (:wsmwk)]

What do you think about putting resolving this on the plate for the next version?

Ref https://www.reddit.com/r/Thunderbird/comments/p39sau/does_gmail_oauth_work/

Comment 15

[Matt]

On reflection, I think we should offer to enable cookies yes or no, rather than just the ones for Gmail. While those servers currently used is reasonably well known, they are not part of some API that Google publish and are probably subject to change without notice. A maintenance issue going forward.

I think just offer to enable everything. If the user want to restrict the cookies to a particular server or set of servers, that should be something they do manually after saying no to enabling cookies.

Comment 21

[Flex]

At least a hint would be nice, because Google for example doesn't give you any clue.

Only after I clicked on "forgot password" I got a message that gave me the hint that this doesn't work because cookies are not enabled.

Comment 23

[Toby Pilling [:tobyp]]

Magnus/Justin, is this still a problem now that we've enabled Oauth in the browser via bug 2019793?

Comment 24

[Justin Tracey [:jtracey]]

It should be fixed for anything that uses the external browser flow, in the sense that it's now only a problem if they're a weirdo like me who has a default browser with JS or cookies disabled (but in that case, the user should presumably know that, be able to see what's going on, and know how to fix it). I don't know whether Yahoo! requires JS or cookies for their flow, feel free to ping if you want me to test all three combinations of that.

Comment 25

[Magnus Melin [:mkmelin]]

What Justin said, but yes only when that flow is used.

Comment 26

[Nico D.]

Some data for comment #24, measured on a current build. The internal flow is still used by o2.mail.ru, oauth.yandex.com, login.aol.com and comcast.net. login.yahoo.com falls back to it when Thunderbird is not the registered net.thunderbird: handler, and any provider does when mailnews.oauth.useExternalBrowser is false. Moving those four providers to the external flow would therefore not close this bug: the internal flow stays as the fallback, bug 2019793 keeps https redirect targets on it by design, and users can force it with that pref.

What the internal flow does today when cookies are off: the authorization page cannot reach storage, never renders its form, and the request neither succeeds nor fails. Nothing in OAuth2.sys.mjs or browserRequest.js sets a timer, so it sits there until the user dismisses the window, and since no refresh token is stored, the next sync starts the same thing over. I reproduced it with the in-tree test provider. The window is already told what happened - it registers with NOTIFY_ALL and receives onContentBlockingEvent with STATE_COOKIES_BLOCKED_ALL - but browserRequest.js implements that callback as an empty function.

If you would like, I can have a go at showing a hint about the disabled cookies there, so that the user at least learns why the page is stuck.

Btw, on the older discussion whether Thunderbird should work around the user's decision to disable cookies: I do not think we should. If someone switches cookies off, that is what they want, and it comes with limitations. This is one of them. What we owe the user is the information that this is the reason, instead of a sign-in that dies silently.

Comment 27

[Toby Pilling [:tobyp]]

That would be very cool, thanks a lot for the offer!

Comment 29

[Nico D.]

Attachment: Screencast: the notification in the sign-in window, with and without the button

Screencast of the hint offered in comment #26 (patch in progress), recorded against Fastmail and Yahoo. One correction to that comment: how far the page gets before it dies varies by provider - Fastmail never renders its form, Yahoo takes the username and stops there - so the notification only says that blocked cookies can stop the sign-in.

What the video does not show is the idea this bug has carried since 2015: adding a cookie exception for the sign-in page. It cannot work. With "Accept cookies from sites" unticked, ShouldAllowAccessFor in StorageAccess.cpp returns before any permission is read, so an exception lets cookies through but never the storage the page needs. Measured with the exception in place: the cookies do get stored, and the page gets one step further, as far as a password prompt. I had no working account to take it past that, so the evidence here is the source, not a completed sign-in.

So the window offers the setting itself, or nothing. Pressing the button turns cookies back on, reloads the page, and the sign-in carries on. Where an administrator has locked the setting, the notification comes without a button. With cookies allowed, nothing is shown.

Comment 30

[Nico D.]

Attachment: Bug 1174797 - Point out blocked cookies in the sign-in window. r?#thunderbird-reviewers

Blocked cookies can stop a provider's login page from signing the user in. How
far it gets varies - one page never renders its form, the next takes the
username and stops there - but nothing times out, so the window sits there, and
because no token is stored the next sync starts the same thing over. The window
is already told what happened - it listens with NOTIFY_ALL - but
onContentBlockingEvent was empty.

Whether the page may use cookies is decided by the setting and by any exception
over the page, not by the request that was blocked: providers load analytics,
advertising and consent domains whose cookies are blocked while the sign-in
works. The notification names the reason and offers to turn cookies back on.
Where an administrator has locked the setting or set the exception, it comes
without the button, because the user could not change it anyway.

The window belongs to OAuth2.sys.mjs, so this covers mail, calendar and
address book sign-ins alike, as well as the chat protocols that ask for the
same window. The test provider now drops its login form when it cannot store a
cookie, which is how the real ones behave.