Change #1150025 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WikimediaEvents@master] EmailAuth: Do not exempt bots

https://gerrit.wikimedia.org/r/1150025

This will break quite a few bots. Looking through the user agents, only a handful provide contact information (and not the highest volume bots). I agree that we should do this, but might need to do a last attempt at outreach before deploying this?

Using action=login with a normal (non-bot) password has been deprecated since rMW54d58ef50665: API changes for AuthManager, a little under a decade ago. So it's unfortunate for those users, but that was an unusually long grace period even by Wikimedia standards.

A few bots (about 1% of the total login volume) use action=clientlogin, which is not deprecated, but its documentation makes it clear that (unlike with bot passwords / OAuth) the client might receive an interactive challange during login. This is not the first example of such changes (e.g. the password policy updates a few years ago changed the action=clientlogin response to bots with weak password). That API is generally not meant for automated login. (Yes the module name is not helpful.)

That said, sure, outreach first is always a good idea.

Ok, so for tech news, something like this?

Bot accounts that are not using bot passwords (https://www.mediawiki.org/wiki/Manual:Bot_passwords) for logins will no longer be able to login, starting the week of June 2. Logging in with a normal (non-bot) password has been deprecated since 2016 (https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/3EEMN7VQX5G7WMQI5K2GP5JC2336DPTD/)

In T395205#10856132, @kostajh wrote:

Ok, so for tech news, something like this?

Bot accounts that are not using bot passwords (https://www.mediawiki.org/wiki/Manual:Bot_passwords) for logins will no longer be able to login, starting the week of June 2. Logging in with a normal (non-bot) password has been deprecated since 2016 (https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/3EEMN7VQX5G7WMQI5K2GP5JC2336DPTD/)

In general, at list of bots would be preferred (since we clearly know them).. but as this is security related that might add a bit of risk ? At the very least an indication of impact is a good idea. x bots currently would stop working if not corrected before this date.

Change #1150627 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/core@master] ApiLogin: Log user agent and user name

https://gerrit.wikimedia.org/r/1150627

In T395205#10856179, @TheDJ wrote:

In T395205#10856132, @kostajh wrote:

Ok, so for tech news, something like this?

Bot accounts that are not using bot passwords (https://www.mediawiki.org/wiki/Manual:Bot_passwords) for logins will no longer be able to login, starting the week of June 2. Logging in with a normal (non-bot) password has been deprecated since 2016 (https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/3EEMN7VQX5G7WMQI5K2GP5JC2336DPTD/)

In general, at list of bots would be preferred (since we clearly know them).. but as this is security related that might add a bit of risk ? At the very least an indication of impact is a good idea. x bots currently would stop working if not corrected before this date.

@TheDJ See P76424, restricted to WMF-NDA. This is data for the last 7 days of login requests from user accounts in the bot group that are bypassing EmailAuth's checks on regular logins via api.php or Special:UserLogin

More specifically:

• If they are using action=login with a non-bot-password (which has been deprecated in 2016), that will start failing (assuming the LoginNotify check fails for the login, which depends on whether the bot keeps arbitrary cookies and whether it makes edits).
• If they are using action=clientlogin, that will start returning an EmailAuthAuthenticationRequest response (which the bot probably won't be able to handle, so in the end it will also fail). Again assuming the LoginNotify check fails. action=clientlogin is documented to return interactive challenges from time to time, and as such is not suitable for automated login.

Bots using passwords and OAuth are of course unaffected. If your bot still isn't using one of these, you really should fix it.

The minimal-effort version is using a bot password which just requires:

• making sure the bot uses action=login like most bots do (no way to use a bot password with action=clientlogin)
• making sure the bot doesn't hardcode the session cookie name (bot password login uses <wiki>_BPsession rather than <wiki>Session)
• changing the password the bot uses to log in

In T395205#10856132, @kostajh wrote:

Ok, so for tech news, something like this?

Bot accounts that are not using bot passwords (https://www.mediawiki.org/wiki/Manual:Bot_passwords) for logins will no longer be able to login, starting the week of June 2. Logging in with a normal (non-bot) password has been deprecated since 2016 (https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/3EEMN7VQX5G7WMQI5K2GP5JC2336DPTD/)

I am using some bot scripts with my non-bot account but 2FA access. Does this mean I cannot use those scripts further because I am unable to login then?

In T395205#10858386, @Xqt wrote:

In T395205#10856132, @kostajh wrote:

Ok, so for tech news, something like this?

Bot accounts that are not using bot passwords (https://www.mediawiki.org/wiki/Manual:Bot_passwords) for logins will no longer be able to login, starting the week of June 2. Logging in with a normal (non-bot) password has been deprecated since 2016 (https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/3EEMN7VQX5G7WMQI5K2GP5JC2336DPTD/)

I am using some bot scripts with my non-bot account but 2FA access. Does this mean I cannot use those scripts further because I am unable to login then?

Currently, accounts with 2FA enabled do not get prompted for EmailAuth.

In T395205#10856132, @kostajh wrote:

Ok, so for tech news, something like this?

Bot accounts that are not using bot passwords (https://www.mediawiki.org/wiki/Manual:Bot_passwords) for logins will no longer be able to login, starting the week of June 2. Logging in with a normal (non-bot) password has been deprecated since 2016 (https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/3EEMN7VQX5G7WMQI5K2GP5JC2336DPTD/)

Should this mention OAuth consumers in addition to bot passwords?

In T395205#10858386, @Xqt wrote:

I am using some bot scripts with my non-bot account but 2FA access. Does this mean I cannot use those scripts further because I am unable to login then?

Accounts with 2FA enabled cannot do automated login, so chances are you are already using bot paswords or OAuth (which won't be affected by login changes).

In T395205#10858476, @taavi wrote:

Should this mention OAuth consumers in addition to bot passwords?

Yeah, probably better to spell out that that will also keep working.

If they are using action=login with a non-bot-password (which has been deprecated in 2016), that will start failing (assuming the LoginNotify check fails for the login, which depends on whether the bot keeps arbitrary cookies and whether it makes edits).

This assumes the wiki has EmailAuth and is set to fire for those users. As a next step we may completely disable action=login with a non-bot-password in MediaWiki core.

So how about

Starting the week of June 2, bots logging in via action=login or action=clientlogin will fail more often. This is because of stronger protections against suspicious logins. Bots using bot passwords or using a loginless authentication method such as OAuth are not affected. If your bot isn't using one of those, you should update it; using action=login without a bot password was deprecated in 2016. For most bots, this only requires changing what password the bot uses.

for the Tech News?

In T395205#10861925, @Bugreporter wrote:

As a next step we may completely disable action=login with a non-bot-password in MediaWiki core.

Maybe we should, we are nearing the ten-year anniversary of the deprecation. Should be a separate task though (and I'd leave the decision to the API maintainers).

Per discussion with @HCoplin-WMF, let's put this in Tech News and then wait another week before merging the change. And also send an email to wikitech-l.

• Tech News
• wikitech-l email

We can merge the patch after the next branch cut, that will give people almost two weeks to fix their bots.

In T395205#10885984, @Tgr wrote:

• Tech News
• wikitech-l email

We can merge the patch after the next branch cut, that will give people almost two weeks to fix their bots.

This has been the standard mode of logging in for bots for nearly 2 (?) decades and now you want to give 2 weeks notice to get all the bots fixed? Please propose a more reasonable timeline and better communication strategy. Right now it sounds again like the lalalala I don't care API developer breaking stuff and doesn't care about all the bots breaking.

Looking through P76424 I missed some of my bots. For example https://commons.wikimedia.org/wiki/Special:Contributions/GeographBot . According to https://commons.wikiscan.org/user/GeographBot it did 45.000 edits in June. So looks like most of the pywikibot based bots are missing from the list. I assume because the session is cached so log events don't happen a lot. How long can a session be cached these days?
How to get a list of bots that do edit, but for which no botpassword based authentication happened?

In T395205#10893612, @Multichill wrote:

This has been the standard mode of logging in for bots for nearly 2 (?) decades and now you want to give 2 weeks notice to get all the bots fixed? Please propose a more reasonable timeline and better communication strategy.

In my experience the only communication that works is bots actually breaking. Again, we are talking about an API deprecated almost ten years ago. There have been warnings included in every API response and whatnot.

Anyway, what would you consider a reasonable timeline and communication startegy?

How long can a session be cached these days?

Arbitrarily long, in theory. Sessions are discarded from the session store after a day of inactivity. The session cookie expires in one year, but the bot doesn't have to honor that.

How to get a list of bots that do edit, but for which no botpassword based authentication happened?

api=login with a normal password is deprecated (the feature name deprecations are logged under is main-account-login), which means you can check the api-feature-usage dashboard.

api=clientlogin with a normal password is meant to be used for interactive login - it is valid to use it but the API does not offer any stability guarantees for the response, the only safe way to use them is to accept arbitrary responses and convert them into a login form (as explained in the API docs). So there isn't really any way to tell whether a client using that API is doing something wrong. That said, I'd expect few if any clients to actually implement arbitrary form generation, so you can probably just include all uses of that API. You can see its uses on the action API dashboard.
(Pywikibot uses api=clientlogin AFAIK.)

Neither of those are the answer to your question exactly, but 1) I don't see a way to get that list, 2) it wouldn't really be useful as there are plenty of legitimate ways to edit without a bot password login (OAuth, using an interactive bot that conveys action=clientlogin challenges to the user, using a JS-based bot that runs in the browser and reuses your normal session).

Mentioned in SAL (#wikimedia-cloud) [2025-06-08T10:53:48Z] <wmbot~multichill@tools-bastion-12> Switch to botpasswords for T395205

Mentioned in SAL (#wikimedia-cloud) [2025-06-08T10:55:17Z] <wmbot~multichill@tools-bastion-12> Switched to BotPasswords for T395205

Mentioned in SAL (#wikimedia-cloud) [2025-06-08T11:12:32Z] <wmbot~multichill@tools-bastion-12> Switched BotMultichillT to BotPasswords for T395205

Mentioned in SAL (#wikimedia-cloud) [2025-06-08T12:00:24Z] <wmbot~multichill@tools-bastion-12> Switched ErfgoedBot to BotPasswords for T395205, unable to test

Mentioned in SAL (#wikimedia-cloud) [2025-06-08T12:05:07Z] <wmbot~multichill@tools-bastion-12> Checked for T395205 YiFeiBot and SignBot already use BotPasswords

In T395205#10893692, @Tgr wrote:

(Pywikibot uses api=clientlogin AFAIK.)

Pywikibot uses several login methods, see login module

action=clientlogin is used for interactive login with normal password and also for 2FA (since 8.0) and the new EMailAuth (from 10.2).
action=login is used for BotPassword only, implemented with release 3.0.20170403. The deprecated login for normal password was dropped in release 3.0.20200405 (5 years ago)
OAuth login is also supported since 10 years.

In T395205#10856311, @kostajh wrote:

[..] See P76424, [..]. This is data for the last 7 days of login requests from user accounts in the bot group [..] on regular logins via api.php or Special:UserLogin

Notable examples on the list include:

• https://meta.wikimedia.org/wiki/User:Community_Tech_bot
• https://en.wikipedia.org/wiki/User:ClueBot_NG

I suggest that ensure these are migrated before breaking the login API. Not because they're the most important per se, but because they are among the most privileged and we can't expect bots to do better than them, as they are 1) operated by a WMF team, and 2) the most well-known counter vandalism bot on English Wikipedia; which means they likely follow the best practices, have close ties or easy access to devs, English-speaking operators, and a large number of people who may help or reach out.

I think that makes for the most fair measure of how effective our communication has been (visibility of warnings, practices around that, how well written and understandable, what they point to, state of docs, etc) and, assuming it's very effective, how quickly such change is implemented in practice.

In T395205#10897017, @Krinkle wrote:

In T395205#10856311, @kostajh wrote:

[..] See P76424, [..]. This is data for the last 7 days of login requests from user accounts in the bot group [..] on regular logins via api.php or Special:UserLogin

Notable examples on the list include:

• https://meta.wikimedia.org/wiki/User:Community_Tech_bot
• https://en.wikipedia.org/wiki/User:ClueBot_NG

I suggest that ensure these are migrated before breaking the login API. Not because they're the most important per se, but because they are among the most privileged and we can't expect bots to do better than them, as they are 1) operated by a WMF team, and 2) the most well-known counter vandalism bot on English Wikipedia; which means they likely follow the best practices, have close ties or easy access to devs, English-speaking operators, and a large number of people who may help or reach out.

I think that makes for the most fair measure of how effective our communication has been (visibility of warnings, practices around that, how well written and understandable, what they point to, state of docs, etc) and, assuming it's very effective, how quickly such change is implemented in practice.

That sounds fair to me. I updated the phab paste (P76424), and those with Logstash access can see how I arrived at the list via this query (click the download icon above "user").

@Quiddity should we send an email to the 166 accounts associated with bots that logged-in without using a bot password in the last week? I could get you the list of emails, or we could use Special:EmailUser (sounds tedious, though).

In T395205#10898784, @kostajh wrote:

@Quiddity should we send an email to the 166 accounts associated with bots that logged-in without using a bot password in the last week? I could get you the list of emails, or we could use Special:EmailUser (sounds tedious, though).

Yes, sending a direct communication to the bot-owners, with appropriately urgent wording in the title and intro sentence, sounds good.
However, I don't have access to any method for sending bulk emails (aside from sending a personal email with 166 BCCs -- I could do this if there are not any better options, but I won't be able to answer any followup questions, beyond redirecting them to a docs-page or a preferred communication-channel);
I think it would be better if a "no-replies" system-account sent the email? I'm not sure what the possible existing options are.

In T395205#10901575, @Quiddity wrote:

In T395205#10898784, @kostajh wrote:

@Quiddity should we send an email to the 166 accounts associated with bots that logged-in without using a bot password in the last week? I could get you the list of emails, or we could use Special:EmailUser (sounds tedious, though).

Yes, sending a direct communication to the bot-owners, with appropriately urgent wording in the title and intro sentence, sounds good.
However, I don't have access to any method for sending bulk emails (aside from sending a personal email with 166 BCCs -- I could do this if there are not any better options, but I won't be able to answer any followup questions, beyond redirecting them to a docs-page or a preferred communication-channel);
I think it would be better if a "no-replies" system-account sent the email? I'm not sure what the possible existing options are.

I suggest using sendBulkEmails.php.

In T395205#10861334, @Tgr wrote:

In T395205#10858386, @Xqt wrote:

I am using some bot scripts with my non-bot account but 2FA access. Does this mean I cannot use those scripts further because I am unable to login then?

Accounts with 2FA enabled cannot do automated login, so chances are you are already using bot paswords or OAuth (which won't be affected by login changes).

What does this mean for me? I can no longer use scripts with my 2FA account?

In T395205#10915301, @Xqt wrote:

What does this mean for me? I can no longer use scripts with my 2FA account?

As I wrote elsewhere, you shouldn't assume you can use the clientlogin API with any kind of account, unless you actually render a login form based on it.
That said, as of today accounts with 2FA are always exempt from EmailAuth challenges, and so won't be affected by this task.

Change #1150627 abandoned by Kosta Harlan:

[mediawiki/core@master] ApiLogin: Log user agent and user name

Reason:

Done via I114d43104928733f28576a0307002528dcc0f99c

https://gerrit.wikimedia.org/r/1150627

Me again. Pywikibot-test account has changed using BotPasswords two months ago. Since today an email verification token is recommended ~100 times for several wikis: Wikipedia, Commons, Meta.

Are you sure you are using bot passwords? It's a completely different code path which doesn't invoke authentication providers at all, I can't see how it would trigger verification emails.

In T395205#10989860, @Tgr wrote:

Are you sure you are using bot passwords? It's a completely different code path which doesn't invoke authentication providers at all, I can't see how it would trigger verification emails.

You meant I use clientlogin action instead of login action? Surely not. Here are the results:

>>> import pywikibot
>>> s = pywikibot.Site('wikitech:en')
>>> s.username()
'Pywikibot-test'
>>> s.logged_in()
False
s.login()
Logging in to wikitech:en as Pywikibot-test

I made some additional print statements during login for debugging.
username: Pywikibot-test
password: <bot suffix>@<botpassword>
action: login
login request: /w/api.php?action=login&lgname=Pywikibot-test&lgpassword=<bot suffix>@<botpassword>&lgtoken=<login token>

>>> s.logged_in()
True
>>> s.user()  # name of logged-in user
'Pywikibot-test'

I guess /w/api.php?action=login&lgname=Pywikibot-test@<bot suffix>&lgpassword=<botpassword>&lgtoken=<login token> would also work because
canonicalizeLoginData normalizes it.

I have several bots that have bot flag in many wikis, and still don't use bot passwords due to severe issue, about which I created phab ticket ~5 years ago. I checked "apihighlimits" when creating botpassword, but after logging in under this botpassword, maximum number of rows in API answers to this bot's requests lowered from 5000 to 500, like any non-bot user. My ticket was completely ignored by developers (it's hard to even find it now, because I created many tickets).

In T395205#10991077, @MBH wrote:

(it's hard to even find it now, because I created many tickets).

This one: T258057: APIhighlimits doesn't work on my bot (with bot password) since July 15, 2020 ?

Yes.

OpenRefine users are reporting that authenticating with a bot password stopped working a few days ago. Has there been additional changes that could have caused this?

In T395205#11119534, @Abbe98 wrote:

OpenRefine users are reporting that authenticating with a bot password stopped working a few days ago. Has there been additional changes that could have caused this?

probably related to T400119?

@Johannnes89 ah, yes of course! Thank you.