In T403383#11988318, @Dreamy_Jazz wrote:

@kostajh do we still want to do this?

In T427497#11983972, @kevinbazira wrote:

We have updated the liftwing_client to support this new cope-b-a4b endpoint and shared it with the PSI team to continue using it to fine-tune their policies.

@dom_walden I think this one could skip QA, but I will leave it for you to review.

@tappof I made the patch for this without having seen that you've claimed it, sorry about that. I've tagged you as a reviewer.

In T427887#11976141, @Dreamy_Jazz wrote:

I tested this using the Wikipedia Android App. Moving to QA for that to be double checked

A separate ticket is probably needed for enabling support in the apps?

In T427887#11975406, @Dreamy_Jazz wrote:

I'm guessing the app code does not actually use DiscussionTools code beyond just calling it's API?

Perhaps we can exempt the apps from hCaptcha code in DiscussionTools until they have a chance to update. For lack of a better approach, we could probably just detect the apps based on their user agent

It also does not work on the iOS app.

Should be fixed now. Thank you for filing the task, @neriah

In T427625#11967436, @Aklapper wrote:

Removing as 1.47.0-wmf.4 train blocker as the 1.47.0-wmf.4 train has already passed.

Probably due to T426387: Enforce php strict types in extensions stewarded by Product Safety and Integrity (plus ConfirmEdit)

While we heard feedback that showing the blocked icon for temporary blocks on named accounts wasn't acceptable, I think for temporary accounts we could make an exception, since most temporary account users would be unlikely to return after a non-indefinite block, and some non-indefinite blocks will last longer than the temporary account session.

@DanielQ do you think this is still needed, given that we have hCaptcha in use now for the showcaptcha consequence? It varies its difficulty based on various metrics.

Resolving this per https://diff.wikimedia.org/2026/05/04/better-detecting-bots-and-replacing-our-captcha-part-2

In T422222#11954710, @dom_walden wrote:

In T422222#11954208, @kostajh wrote:

Thanks for letting me know. I've seen this too. This one might relate to peculiar issues with the networking set up between client / BrowserStack / WMF proxy, rather than grade C compatibility. Could you retry it on testwiki please?

I have just tried on testwiki on browserstack and a local version of Firefox 49 and see the same errors.

In T422222#11948345, @dom_walden wrote:

In T422222#11945319, @kostajh wrote:

In T422222#11945255, @gerritbot wrote:

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

[mediawiki/extensions/ConfirmEdit@master] hCaptcha: Avoid `for (const ... of ...)` in Grade C bundle

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

This should fix the Firefox 50 and 49 cases noted above; still working on Chrome 50 and 49.

@kostajh Works for Firefox 50, but I still cannot get this to work for Firefox 49 . I see There was an error while loading the form.... Error in the console:

error.confirmedit Error: Unable to load hCaptcha script (retrying)
Stack trace:
loadHCaptcha/</onErrorCallback@http://blackbird:8080/w/load.php?modules=ext.confirmEdit.hCaptcha.gradeC&only=scripts&raw=1&version=12phd:144:967
load.php:140:764

None of the sha384 hashes in the integrity attribute match the content of the subresource.index.php
error.confirmedit Error: Unable to load hCaptcha script (retrying)
Stack trace:
loadHCaptcha/</onErrorCallback@http://blackbird:8080/w/load.php?modules=ext.confirmEdit.hCaptcha.gradeC&only=scripts&raw=1&version=12phd:144:967
load.php:140:764

error.confirmedit Error: Unable to load hCaptcha script (terminal)
Stack trace:
loadHCaptcha/</onErrorCallback@http://blackbird:8080/w/load.php?modules=ext.confirmEdit.hCaptcha.gradeC&only=scripts&raw=1&version=12phd:144:967
load.php:140:764

In T418175#11948274, @MLechvien-WMF wrote:

Hi, can I confirm that https://wikitech.wikimedia.org/wiki/SLO/ipoid should now redirect to https://wikitech.wikimedia.org/wiki/SLO/OpenSearch_IPoid ?

cc @kostajh @RLazarus

In T426323#11947857, @Clement_Goubert wrote:

While investigating with @hnowlan he observed the cache-control header was not being added correctly to responses coming through the rest-gateway.

Well it turns out that if your cache-control header is added to the request and not the response, it doesn't work. The setting we use, cache-control: no-cache, means "revalidate the response with the backend before serving cached content" (and not "don't cache the content at all").

Fixing that and purging https://api.wikimedia.org/service/lw/recommendation/api/v1/translation/page-collection-groups makes the CORS errors go away, mostly because the responses are now always cache misses.

I introduced this error when migrating the routes from the api-gateway to the rest-gateway and didn't catch it, my apologies.

I'm resolving this task, feel free to reopen if you disagree.

In T422222#11945379, @gerritbot wrote:

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

[mediawiki/extensions/ConfirmEdit@master] hCaptcha: Avoid URL.searchParams in Grade C bundle

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

In T422222#11945255, @gerritbot wrote:

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

[mediawiki/extensions/ConfirmEdit@master] hCaptcha: Avoid `for (const ... of ...)` in Grade C bundle

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

In T422222#11944712, @dom_walden wrote:

In T422222#11941348, @kostajh wrote:

@dom_walden desktop wikitext editor and Special:CreateAccount should usable now via a Grade C browser, can you please test this in your local environment, and/or verify it next week when the train is at group0? Thank you!

@kostajh I will keep updating this table. Browser/OS combinations not chosen very scientifically.

Testing locally:

Browser	OS	Edit	Create account
Firefox 57	Windows 8	Working	Working
Firefox 51	Windows 10	Working	Working
Firefox 50	Windows 8.1	Not working-	Not working*
Firefox 49	Windows 10	Not working-
Firefox 49	Mac High Sierra	Not working-
Chrome 62	Windows 8.1	Working	Working
Chrome 51	Windows 10	Working	Working
Chrome 50	Windows 11	Not working+
Chrome 50	Mac Catalina	Not working+	Not working+
Chrome 49	Mac Mojave	Not working+

- After submit: "Incorrect or missing CAPTCHA"
* After submit: "We're not quite finished loading the form..."
+ Before submit: "There was an error while loading the form..."

With the help of https://github.com/liriliri/eruda to surface the console error, I found that this seems to be due to an issue in TestKitchen code. I'll post a patch.

I can reproduce this locally with BrowserStack

We can start work on this. Ideally it lands close to the group2 rollout for hCaptcha.

Resolving per https://diff.wikimedia.org/2026/05/04/better-detecting-bots-and-replacing-our-captcha-part-2/

In T426751#11941573, @dom_walden wrote:

In T426751#11940391, @kostajh wrote:

@dom_walden can you please try to reproduce this issue again?

I can no longer reproduce on testwiki. I have tried making normal edits which trigger the hCaptcha challenge and those which trigger AF (including seeing the hCaptcha challenge twice). I can complete the challenge(s) and save the edit.

Seems to be covered by T424629 and subtasks

I think these levels are manageable (solved by rOPUPb70039d2f97d: hcaptcha: Override upstream Access-Control-Allow-Origin with '*') but would welcome a second review: https://logstash.wikimedia.org/goto/7112989c991486beb99b22ae7d168514

@dom_walden desktop wikitext editor and Special:CreateAccount should usable now via a Grade C browser, can you please test this in your local environment, and/or verify it next week when the train is at group0? Thank you!

This should be fixed. We can continue in T426089: hCaptcha: Enable usage on wikidata.org about actually building support for hCaptcha into various Wikidata editing interfaces.

@dom_walden can you please try to reproduce this issue again?

One idea (h/t @Dreamy_Jazz ) is to apply an exemption, for now, for edits made when the title is a special page.

In T426105#11933806, @jhathaway wrote:

Someone from Yahoo was kind enough to reach out to me directly and modify the IP reputation, so emails are flowing again!