847803 - [email] Detect gmail suspicious login error, provide specialized error/prompt

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

gmail just got angry about letting me connect to my account because I am elsewhere in the world than I usually am.

The IMAP error code string I get is:
[ALERT] Please log in via your web browser: http://support.google.com/mail/accounts/bin/answer.py?answer=78754 (Failure)

Our UI manifested as the "hey, we think you have a bad password!  try entering a new one".  Obviously, re-entering your password won't cure the problem, so displaying a more apt string like "Your provider believes this to be a suspicious connection and requires you to login via a webpage before allowing this connection.  Click [here to login], then retry once you have done that.  [Retry]."  I would avoid making the string gmail specific so we can reuse the strings for other providers too.

That page directed me to go to:
https://www.google.com/accounts/DisplayUnlockCaptcha

From there, I was able to login again, and instructions said that any connections I tried to make in the next 10 minutes would effectively be whitelisted.  The verification was actually more limited than I was expecting; no text message required.  I suspect it probably saw I had good cookies recently established in a non-suspicious location.

Unfortunately, I'm not really clear on whether we can use the same URL to fix things for all locales, or just english ones.  It would be bad if the URL has the language implicitly baked into it.


This is a little similar to the hotmail bug 826638 about it thinking you are a spammer and block SMTP access until a CAPTCHA is cleared.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Okay, so the unlock URL does seem to be consistent across locales.  Or at least, googling site:support.google.com https://www.google.com/accounts/DisplayUnlockCaptcha netted me various URLs in other languages that reference the URL. ex:
http://support.google.com/accounts/bin/static.py?hl=es&page=ts.cs&ts=2402620&from=2402620&rd=2
http://support.google.com/mail/bin/answer.py?hl=zh-Hant&answer=14257

That just leaves the error detection.

One broader possibility is just to detect a URL in the error message and to just show the user the server's error message and let them follow the URL, then possibly re-enter their password or just retry when they return.  The downside to that is that, at least in this case, the google support page is not as clear as us just telling the user to go to the unlock page.

Casey, thoughts?

Comment 2

[Alex Keybl [:akeybl]]

(In reply to Andrew Sutherland (:asuth) from comment #0)
> Our UI manifested as the "hey, we think you have a bad password!  try
> entering a new one".  Obviously, re-entering your password won't cure the
> problem, so displaying a more apt string like "Your provider believes this
> to be a suspicious connection and requires you to login via a webpage before
> allowing this connection.  Click [here to login], then retry once you have
> done that.  [Retry]."

For v1-train, we should find the lowest risk solution. Perhaps it would be to just recognize the error and display "Your provider believes this to be a suspicious connection and requires you to login via a webpage before allowing this connection" (without buttons)?

Comment 3

[Casey Yee]

(In reply to Andrew Sutherland (:asuth) from comment #0)
> The IMAP error code string I get is:
> [ALERT] Please log in via your web browser:
> http://support.google.com/mail/accounts/bin/answer.py?answer=78754 (Failure)

Could we just use window.open or load the URL directly into the browser on alerts of this type?  It's what the user needs to do anyways to get the issue resolved.  The explanation/fix instructions also look clear enough that we might not really need to present any errors on the mail app side.

I'm guessing there may be more of these kinds of alerts as well.  Might be good to handle these in a generic manner.  Is there anywhere we can snoop for all the possibilities?

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Casey Yee [:cyee] from comment #3)
> Could we just use window.open or load the URL directly into the browser on
> alerts of this type?  It's what the user needs to do anyways to get the
> issue resolved.  The explanation/fix instructions also look clear enough
> that we might not really need to present any errors on the mail app side.

I think we might be able to trigger window.open without the user clicking on anything right now, but eventually we might need to have the user actually click on someething for security reasons.  (web activities need must be the result of a user action, but window.open avoids that right now.)

That does seem pretty reasonable.
 
> I'm guessing there may be more of these kinds of alerts as well.  Might be
> good to handle these in a generic manner.  Is there anywhere we can snoop
> for all the possibilities?

We could run a regexp for a URL against any errors returned by the server and show a page and/or automatically kick out to the web browser when we detect URLs.  The use of URLs is somewhat uncommon, even for gmail.  For the other 3 gmail cases we specifically handle, no URL is included, but it's possible this has changed since we implemented them or would change. By having the regexp path be an explicit fallback path rather than overriding the cases we already handle, we could avoid regressions in our functionality.

Comment 6

[BMO Automation]

Firefox OS is not being worked on