See also T150699
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Add basic 2FA support | apps/android/wikipedia | master | +137 -11 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | None | T100375 Improve user experience of Two-Factor process | |||
Resolved | Dbrant | T150899 Support 2FA in Wikipedia Mobile applications | |||
Invalid | None | T151227 Update authentication flows | |||
Resolved | • Mholloway | T150900 [Android] Allow users to log in with 2FA in the app | |||
Resolved | • Niedzielski | T150529 every edit save fails on 2.4.180-alpha-2016-11-10 | |||
Resolved | • Mholloway | T154414 every edit save fails, Invalid CSRF token |
Event Timeline
If this is the behavior of the current production release and not a regression, I don't think it's a blocker. If it is, this should be changed to unbreak now and a hotfix release should be considered.
FWIW, I'd at least handle the login better, and give some sort of useful error message. Currently it's mostly silent failure, and no indication what's wrong if you've enabled 2FA, just tries to login and goes back to the login screen.
Yes, 2FA should be supported (it is on the normal mobile site), but I'm not sure it's a major blocker, as long as like I say, you at least handle the error a bit better
Same behavior in all versions. I was writing up a separate task on login problems when I figured out what was going on. (I just got 2FA enabled on my staff and personal accounts yesterday.)
FWIW I don't think this will be a tough fix. We just need to add some logic to LoginClient to handle this response.
And yeah, we should make sure a blank snackbar isn't firing in the general case of an unrecognized response.
The app is using clientlogin but hardcoding what responses it expects. Ideally, it would implement the full AuthManager API instead (that is, form generation from a descriptor that you get from the authmanager info API instead of presupposing anything about the fields). That might be a lot of work though.
Totally agree on providing better error feedback when TFA is enabled. Let's first understand the technical magnitude of adding TFA support for logging in. If it's a matter of adding one more parameter to the login request (and one more input field to our login screen), then we can just add it. If it's more complex than that, we'll just improve the error feedback, and prioritize full support for TFA for a later time.
Apparently, there's ways to link into Google Authenticator to have it fill the field automatically. I don't know how much work that would be, but would be a "nice to have" in the future
Another report (by @JD) about the same issue: https://de.wikipedia.org/wiki/Wikipedia_Diskussion:Technik/Mobil/App#2FA.3F
@Matanya, unmerged patch alpha build :] https://drive.google.com/file/d/0B0mn_ZbhnHPWZmpiYlZock9kWkE/view?usp=sharing