@Tgr Would you be able to confirm that the change outlined in the description is accurate? And if so, are there any other changes we should be on the lookout for?

I suppose this is a side effect of various captcha-related classes getting namespaced in rECOE30cd1d8a23ac: Namespace base classes (cc @Reedy). AuthManager uses the fully qualified classname as the default ID, which is not great, but I'm not sure there's a better default behavior. Authentication request classes are supposed to override AuthenticationRequest::getUniqueId() for a stabler ID, but I don't think we have put in any energy to make that actually happen. Sorry.

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

[mediawiki/extensions/ConfirmEdit@master] Restore auth request ID from before namespacing

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

In T316410#8190647, @Tgr wrote:

Authentication request classes are supposed to override AuthenticationRequest::getUniqueId() for a stabler ID, but I don't think we have put in any energy to make that actually happen. Sorry.

Or maybe they aren't supposed to; it's not documented as such, and nothing seems to be doing it. In any case, it can be done as a generic short-term fix. In general, I think the field names under fields are more useful to look at for detecting certain kinds of requests; those are supposed to be stable (and mostly correlate 1:1 to form fields).

Thanks for looking into it! We can also easily update the client side to handle the fully-qualified case, too (or use the fields names instead), but it will take a while for existing installs to get updated, so if there is a short-term fix on your end, that would be a big help.

We can deploy it on Monday if it isn't an emergency (the original patch went live with wmf.24 so I assume it isn't).

In general I think you are better off using fields names (possibly in combination with amimergerequestfields=1 which makes the response structure a bit simpler) - they do not depend on the class name and would need an intentional effort to change, and are usually a little more meaningful.

Alternatively, we could recommend for providers to use a stable value for getUniqueId(), and update Wikimedia-deployed ones. Originally it was just meant for deduplication (some request types can occur multiple times, e.g. if you are using a "log in via OAuth" button and your wiki is conifigured to accept multiple identity providers), but then it seems bad form to expose something to clients, call it an ID, and make in depend on PHP class structure.

In T316410#8190647, @Tgr wrote:

I suppose this is a side effect of various captcha-related classes getting namespaced in rECOE30cd1d8a23ac: Namespace base classes (cc @Reedy). AuthManager uses the fully qualified classname as the default ID, which is not great, but I'm not sure there's a better default behavior.

Yeah, we've got quite a few code assumptions around classnames, and that they won't change... Or they won't get namespaced (which is very unlikely)

T277414: HTMLFormField and subclasses use static::class to make css class names for a similar issue...

Change 826621 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] Restore auth request ID from before namespacing

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

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

[mediawiki/extensions/ConfirmEdit@wmf/1.39.0-wmf.26] Restore auth request ID from before namespacing

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

Change 827203 merged by Clare Ming:

[mediawiki/extensions/ConfirmEdit@wmf/1.39.0-wmf.26] Restore auth request ID from before namespacing

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

Mentioned in SAL (#wikimedia-operations) [2022-08-29T20:53:37Z] <cjming@deploy1002> Synchronized php-1.39.0-wmf.26/extensions/ConfirmEdit/includes/Auth/CaptchaAuthenticationRequest.php: Backport: [[gerrit:827203|Restore auth request ID from before namespacing (T316410)]] (duration: 03m 45s)

@Dbrant should be fixed in production.

@Tgr Much appreciated!