Support Bot Password authentication

[Kota-Jagadeesh]

Description (required)

Fixes #6714

What changes did you make and why?

because the standard clientlogin API rejects bot passwords, users with WebAuthn/2FA are currently locked out of the app. To fix this:

• i added a new postBotLogIn Retrofit endpoint using the action=login API.
• and added routing logic in LoginClient to check if a username contains an @ symbol, dynamically sending bot users to the new endpoint and regular users to clientlogin.
• and added safe JSON parsing in LoginResponse using JsonElement to handle the bot login responses.

Note: Leaving this as a draft while I wait for the mailing list confirmation regarding the API endpoints

Tests performed (required)

Tested ProdDebug on Redmi Note 13 Pro with API level 35.

• Successfully authenticated and logged in using the bot password credentials.
• Verified that standard accounts still route correctly to clientlogin and handle 2FA blocks as expected.
• check [Feature]: Support logging in using bot password #6714 (comment) for the video clip.

Screenshots (for UI changes only)

N/A - No ui changes yet!

[Kota-Jagadeesh]

hi @sivaraam! got the reply from tthe mailing list, and they confirmed our approach is good to go!

1. regarding clientlogin: they confirmed that clientlogin intentionally rejects bot passwords by design. action=login is the officially supported backwards-compatibility mechanism for mobile apps using bot passwords

2. and regarding the `@`` symbol: they confirmed that for official Wikimedia wikis, normal usernames cannot contain @. since our app connects to Wikimedia infrastructure, checking for the @ symbol to route the login request is safe. 🙂

[Kota-Jagadeesh]

their exact replies in the mailing list :

When passing Bot Password credentials (Username@BotName and the 32-character password) to action=clientlogin, the API rejects it with a wrongpassword error. however, passing the exact same credentials to the action=login endpoint succeeds. Is it intended design that clientlogin strictly rejects bot passwords, and is action=login the officially supported endpoint for this specific flow??

Yes, bot passwords were originally meant as a backwards compatibility mechanism for old bots using the action=login endpoint. (Modern bots are encouraged to use OAuth instead, but for mobile apps the support for that is not so great, so bot passwords are probably still the least bad option. We hope to improve that soon.)

To dynamically route the login requests in the app's code, rn i am currently checking if the entered username contains an @ symbol. If it does, route to action=login; if it doesn't, then route to action=clientlogin. Since standard MediaWiki usernames cannot contain the @ symbol by default , is it 100% safe to assume any login attempt containing an @ is a Bot Password attempt?

For Wikimedia wikis, yes. In general, it is configurable, so I guess it's theoretically possible some wiki out there would still have it enabled.

[Kota-Jagadeesh]

also, i have implemented the idea about the permissions! > it's good that not letting the users log in if they don't have the right privileges. I will update the PR in the evening after my college ends.

[github-actions]

✅ Generated APK variants!

• 🤖 Download prodDebugAPK
• 🤖 Download betaDebugAPK

[Kota-Jagadeesh]

hi @sivaraam, i updated thhe pr to make the authentication flow much more better, including the permissions validation you suggested! 🙂

• for the permission validation i added an api call right after a bot login to verify they actually have the required rights. if they don't, it stops and tells them to recreate the password by giving the required rights to login into the app.
• fixed the session conflict to handle the badsessionprovider ghost session bug gracefully so the app doesn't crash if they switch accounts or try logging in twice

i also attached the screen recording below showing all the test cases:

1. testing normal wikimedia credentials -> successfully logs in
2. logging in with a bot password that has full rights -> successfully logs in
3. logging in with a bot password that has only the strictly required rights -> successfully logs in
4. trying to log in with a bot password that is missing rights -> correctly blocked with the clear "insufficient permissions" error telling them to recreate the password.

please review the changes when you have a chance and let me know if anything needs adjusting! :)

screen record clip :

Screenrecorder-2026-03-13-20-42-19-415.mp4

[sivaraam]

Wonderful, @Kota-Jagadeesh

Let's check and get this merged soon :-)