Google account login using 2FA isn’t remembered across sessions

[Olivier Tilloy]

This has been reliably reproduced on desktop and a phone running webbrowser-app 0.23+16.04.20160711-0ubuntu1 (and oxide 1.15.8-0ubuntu0.16.04.1).

Steps to reproduce:
1) wipe your session data (make a backup first if you care) by removing ~/.local/share/webbrowser-app/
2) launch webbrowser-app
3) browse to https://mail.google.com
4) log in with an account that uses 2FA (I’m testing with a @canonical.com address)
5) read your e-mails
6) close the browser window
7) launch webbrowser-app again

Expected result: you’re back to your inbox, logged in and ready to work

Actual result: google prompts you for your e-mail address. Once entered, the login happens automatically, there is no need to do the 2FA dance again.

[David Barth (dbarth)]

I think this is really a Google feature, not a bug.

From what we observed, corporate / 2fa accounts userids are stored as /session cookies/ and thus only survive for the lifetime of a browser session. We think this is on purpose, to force an userid confirmation "every morning" or so, as defined by a new browser session start.

[Olli Ries (ories)]

I can confirm that Chrome does not show that behavior, i.e. it does let me login without having to enter the credentials again.

Chromium however does show the behavior described in comment #1.

However, webbrowser-app does require the userid (email) entered again before letting you log in.

[Alberto Mardegan (mardy)]

As David wrote, this behaviour is due to the fact that Google corporate accounts store their session in session cookies, which are normally cleared when the browser is closed.

Now, when using Chromium in the desktop, session cookies are restored, if the user has chosen that on startup the last session should be shown; in all other cases, they are cleared.
Reference:
http://stackoverflow.com/questions/10617954/chrome-doesnt-delete-session-cookies
https://bugs.chromium.org/p/chromium/issues/detail?id=128513

In our GMail (and other Google-affiliated) webapp we set the cookie mode to "restored", in order to preserve the authenticated session between restarts. That's the obvious right thing to do in a webapp.

For webbrowser-app, the behaviour is a bit more questionable, but given that webbrowser app usually starts with showing the last page the user visited, and keeps all tabs active, I would guess that the most natural behaviour would be to remember session cookies, in the same way that Chromium does when it's restoring the last visited tabs.

[David Barth (dbarth)]

To confirm, you can use a guest session, and re-do the test here. You will not be logged in automatically after a browser restart, due to the use of session cookies by the Google Account service.

As pointed out by mardy, the behavior observed in the bug report is due to a chrome feature called "continue where you left off", where chrome doesn't delete the session cookies used for storing that (temporary) username variable.

Ref: http://stackoverflow.com/questions/10617954/chrome-doesnt-delete-session-cookies

[Olivier Tilloy (osomon)]

Re-opening as our browser by default continues where the user left off (it restores all open tabs). So we should probably set the cookie mode to restored in the default case, and set it to ephemeral when the user launches the browser with the --new-session command-line flag.

[Chris Coulson (chrisccoulson)]

The only time the browser should restore session cookies is after a crash or some other abnormal shutdown. Restoring should never be the default as it turns session cookies in to permanent cookies - they will never expire, as they don't have an expiration date.