Related: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/1265608 (and I assume T420154, which is private but linked to the patch)

This change also broke Tool-quickcategories:

mwapi.errors.APIError: echo-read-notifications: You don't have permission to $1. -- See https://meta.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes.

[2026-04-03 11:23:06,630] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/flask/app.py", line 1511, in wsgi_app
    response = self.full_dispatch_request()
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/flask/app.py", line 919, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/flask/app.py", line 917, in full_dispatch_request
    rv = self.dispatch_request()
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/flask/app.py", line 902, in dispatch_request
    return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/workspace/app.py", line 338, in index
    return flask.render_template('index.html',
           ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^
                                 default_domain=flask.session.get('default-domain', None),
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                 suggested_domains=flask.session.get('suggested-domains', []),
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                 batches=batch_store.get_batches_slice(offset=0, limit=10),
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                 read_only_reason=app.config.get('READ_ONLY_REASON'))
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/flask/templating.py", line 150, in render_template
    return _render(app, template, context)
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/flask/templating.py", line 131, in _render
    rv = template.render(context)
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/jinja2/environment.py", line 1295, in render
    self.environment.handle_exception()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/jinja2/environment.py", line 942, in handle_exception
    raise rewrite_traceback_stack(source=source)
  File "/workspace/templates/index.html", line 1, in top-level template code
    {% extends "base.html" %}
  File "/workspace/templates/base.html", line 21, in top-level template code
    {{ authentication_area() }}
    ^^^^^^^^^^^^^^^^^^^
  File "/workspace/app.py", line 151, in authentication_area
    raise e
  File "/workspace/app.py", line 140, in authentication_area
    response = session.get(action='query',
                           meta=['userinfo', 'notifications'],
                           notcrosswikisummary=True,
                           notprop=['count'])
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/mwapi/session.py", line 308, in get
    return self.request('GET', params=params, auth=auth,
           ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        query_continue=query_continue,
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                        continuation=continuation)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/mwapi/session.py", line 171, in request
    return self._request(method, params=normal_params, auth=auth,
           ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                         files=files)
                         ^^^^^^^^^^^^
  File "/layers/heroku_python/venv/lib/python3.13/site-packages/mwapi/session.py", line 127, in _request
    raise APIError.from_doc(doc['error'])
mwapi.errors.APIError: echo-read-notifications: You don't have permission to $1. -- See https://meta.wikimedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes.

(The uninterpolated $1 in the error message is also not ideal.)

Edit: workaround

Mentioned in SAL (#wikimedia-cloud) [2026-04-03T11:34:32Z] <wmbot~lucaswerkmeister@tools-bastion-15> deployed eb7875d76b (temporarily disable notifications feature to unbreak tool: T420154, T421991)

Can someone explain the rationale for this breaking change? Some users of AutoWikiBrowser are suddenly unable to edit because this new error element stops everything. I think they are using a bot account not for a bot but as a workaround for the introduction of email auth last summer (we addressed that in the tool but not everyone has that fix). And AWB has a genuine bot mode.

The AutoWikiBrowser community has been on a wild goose chase since this feature was rolled out. As it is happening the same time as rate limit changes, at first we suspected that (it has a similar appearance in the UI).

I have to say, the message "You don't have permission to $1." is singularly unhelpful, even when we tracked it down to a specific API query. Some ordinary interactive users started logging in with a bot account/password when the EmailAuth feature was sprung on us, and have kept it even after the UI was updated (long story).

Since this is a breaking change, as confirmed in the gerrit submission, from an API user's POV, I must have missed some announcement. I'm fairly new to maintaining this 20 year old app. What should I have subscribed to?

In T421991#11787201, @DavidBrooks wrote:

Can someone explain the rationale for this breaking change? Some users of AutoWikiBrowser are suddenly unable to edit because this new error element stops everything. I think they are using a bot account not for a bot but as a workaround for the introduction of email auth last summer (we addressed that in the tool but not everyone has that fix). And AWB has a genuine bot mode.

This is part of a mitigation for a security issue that was discovered recently. I don't know how much details can be shared in public at that point. @Michael may be able to provide more information.

At least the title of the security issue has been made public: "(T420154, CVE-2026-5266) SECURITY: Notifications (Echo) API can be used by any OAuth tool." (https://lists.wikimedia.org/hyperkitty/list/mediawiki-l@lists.wikimedia.org/thread/DIBLSBHISKX6NFRUFNOGZRVW42E7R2QP/) I asked for the task to be made public as well.

Patch https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/1266286 will resolve this once it's deployed (it was tagged against the security-restricted task). You will need to update your consumers and bot passwords to grant them the new permissions afterwards.

My bot is broken as well. Can we consider a backport for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/1266286 since it sounds like that patch will fix everything?

edit: Looks like we'd have to backport like 3 patches, making backporting hard. Maybe this will have to wait until the train on Thursday.

Also, You don't have permission to $1. The $1 seems like a minor bug that also needs fixing. (I was able to reproduce this.)

Change #1268099 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):

[mediawiki/extensions/Echo@master] ApiEchoPermissionsTrait: don't show $1 to user

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

Can the new permission be defaulted to true for normal (not bot) users? It would might simplify things on the client side.

This issue should now be fixable on the bot owner's side: Receiving access to notification now requires the echo-read-notifications grant, which can be requested at https://meta.wikimedia.org/wiki/Special:BotPasswords (for those authenticated via a bot password) or at https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration (for those using OAuth).

In T421991#11788504, @Novem_Linguae wrote:

My bot is broken as well. Can we consider a backport for https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/1266286 since it sounds like that patch will fix everything?

I was waiting for the deployment window. All should be backported now.

I can confirm that it works again after the permission has been set.

I realize this task is closed, but I still have a question/problem. Hope someone is still reading.

Some users of AutoWikiBrowser are logging in with a bot password, let's say as "DavidBrooks@AWB". After going through the login API, the lgusername is "DavidBrooks", and after a userinfo query it is neither in group "bot" nor has right "bot".

However, this new restriction treats the logged in user as a bot and returns the error about notifications not allowed to the interactive user.

Right now I have a hotfix that skips the notifications query if the username originally presented to login contains an @ (or has the bot group membership or right) but that feels like a hack. This was somewhat behind my question about default for non-bot users.

So, question: in this scenario, will the https://meta.wikimedia.org/wiki/Special:BotPasswords method work? It may anyway be difficult to reach all AWB users, especially as using a a BotPassword was advertised as a quick fix for the sudden appearance of EmailAuth last summer. I may just promote the hotfix from temporary to permanent for that reason.

ETA: yes, it does work. We just have to message any users who are not clued in to the internal discussion.

Change #1268099 merged by jenkins-bot:

[mediawiki/extensions/Echo@master] ApiEchoPermissionsTrait: don't show $1 to user

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

@DavidBrooks Indeed, "bot passwords" is a bit of a misnomer, and something like "application passwords" would be more accurate. They work for any account, but when they were introduced in 2015, bots were the main use case, and we wanted to encourage other applications to use OAuth instead (and we still want that) [ref: T121113#1881482]. The related AWB task is T150582.

Mentioned in SAL (#wikimedia-cloud) [2026-04-06T23:22:50Z] <wmbot~lucaswerkmeister@tools-bastion-15> deployed d83be52ab9 (reenable notifications feature with new OAuth consumer: T420154, T421991)

Change #1269553 had a related patch set uploaded (by Reedy; author: Novem Linguae):

[mediawiki/extensions/Echo@REL1_45] ApiEchoPermissionsTrait: don't show $1 to user

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

Change #1269554 had a related patch set uploaded (by Reedy; author: Novem Linguae):

[mediawiki/extensions/Echo@REL1_44] ApiEchoPermissionsTrait: don't show $1 to user

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

Change #1269555 had a related patch set uploaded (by Reedy; author: Novem Linguae):

[mediawiki/extensions/Echo@REL1_43] ApiEchoPermissionsTrait: don't show $1 to user

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

Change #1269554 merged by jenkins-bot:

[mediawiki/extensions/Echo@REL1_44] ApiEchoPermissionsTrait: don't show $1 to user

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

Change #1269553 merged by jenkins-bot:

[mediawiki/extensions/Echo@REL1_45] ApiEchoPermissionsTrait: don't show $1 to user

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

Change #1269555 merged by jenkins-bot:

[mediawiki/extensions/Echo@REL1_43] ApiEchoPermissionsTrait: don't show $1 to user

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