That's interesting. Thanks for reporting, Quim.

In theory, as long as you're logged in from the same IP and same device every time, this should not happen. I'm not sure if the app does something strange to cause such behavior. I will check if the behavior with iOS app is similar.

Today it happened again, when QuimGil performed a search for Catalan Wikipedia from the app. I am going to try once per day from now on.

The app is logged in. I am connecting via mobile data.

Another report from a user receiving multiple notifications each time she logs on from her android https://fr.wikipedia.org/wiki/Sujet:U12ms36gt7djise4

He says he's getting failed notices, but successful seems like it would make more sense...

Looking at logs, this account is getting both login-fail-known and login-fail-new, the logged URL is /w/api.php?action=clientlogin&format=json&formatversion=2&rememberMe= in both cases.

That does indeed look like the URL format that the Android app uses...

Do these users have 2FA enabled? (and do the logs say anything about this?)

No.

I can confirm that I use the beta Wikipedia Android app on both of my Android devices. When I visit Wikipedia on the web, I'm greeted with a new message of multiple failed attempted logins. (I also get a corresponding e-mail each time.)

(I didn't test every day as I promised but) Yesterday night it happened again. This time I was clicking a link from a Google Hangout chat in my mobile device to https://en.wikipedia.org/wiki/Wikipedia:Arbitration_Committee/Noticeboard. The link activated the Wikipedia app, and a few seconds after I got the email about the Failed Attempt.

I talked this over a bit with @MaxSem on IRC and he pointed me to this task. I no longer work on the Android team, so my information may be a bit out of date, but I think I've identified a plausible path for this to occur:

When a user launches the app and the app believes the user is logged in, it attempts to sync certain user preferences (stored in userjs) via the API and, in some cases, polls the API for user notifications. In both of these situations the app requests a CSRF token from the API via CsrfTokenClient. If the API returns an anonymous token (+\\) despite the app believing the user is logged in, the app will clear its cookies, retrieve the user's credentials from the system Account Manager, and attempt to log the user back in via the API (action=clientlogin) and retry the token request (source). This login attempt failing for some reason would produce the effect of the user receiving a failed login notification shortly after launching the app, which is what it sounds like @QuimGil and others are seeing.

I'm not sure offhand why this login would fail, but in digging into this issue I did notice a rather smelly bit of code in which the app requests the current user accounts in the system associated with the app and simply takes the first one off the returned list (source). It might not be safe to assume that the first item returned is the one we want, although without further investigation I'm not sure how we'd get into a state in which multiple accounts are registered.

I see this more often when I'm away from home... Is it possible that the app is doing some sort of location/network checking at the same time? Or perhaps has not verified that it has a working Internet connection?

We're still not able to reproduce this behavior ourselves, but @Mholloway's description is essentially correct:

• The app requests a CSRF token (for a variety of reasons)
• If the app believes that the user is logged in, but it receives an anonymous token, it will re-login the current user with credentials stored in Android's AccountManager.

Perhaps the API is logging an error if it receives a stale cookie? Or does it care if the user suddenly starts making requests from a different IP?

Someone reported via OTRS (ticket 2017120510008296) that they were getting a lot of failed login notifications, and they are using the Android app. I don't know for sure if the app was the culprit but I thought I'd let you know in case you wanted to talk to them (you'll need OTRS access, though).

In T178746#3816121, @Dbrant wrote:

We're still not able to reproduce this behavior ourselves, but @Mholloway's description is essentially correct:

• The app requests a CSRF token (for a variety of reasons)
• If the app believes that the user is logged in, but it receives an anonymous token, it will re-login the current user with credentials stored in Android's AccountManager.

Perhaps the API is logging an error if it receives a stale cookie? Or does it care if the user suddenly starts making requests from a different IP?

Failed login attempt notifications are issued if the login is from a new IP (i.e. an IP that is not associated with that user in the CheckUser table). LoginNotify also sets a cookie but that wouldn't work on the app, so it's likely the IP address problem.

Is this still happening? Is this reproducible? Can we close this?