Page MenuHomePhabricator

Invalid IPv6 URL on page causes all non-autoconfirmed edits to trigger CAPTCHA
Open, Needs TriagePublic


  1. On enwiki, create a page containing this invalid link: http://ABCD:0000:0000:0000:0000:0000:0000:0000
  2. With a non-autoconfirmed account, add more text to the page. Do not add any more links.

The expected result is no CAPTCHA. The actual result is a CAPTCHA, even though no new external links were added.

Example: this edit required a CAPTCHA to save.

If the URL is instead formatted correctly, as http://[ABCD:0000:0000:0000:0000:0000:0000:0000], other edits do not trigger the CAPTCHA.

Example: this edit required no CAPTCHA, as expected.

Event Timeline

Here's the series of events going on there:

  • The page is saved containing the bad link.
    • The Parser's output includes the bad link in the ParserOutput metadata.
    • The job for inserting the externallinks table rows for the page runs. For our bad link it gets 0 indexes from LinkFilter::makeIndexes(), so makes no insertion for this bad link.
      • The 0 index entries comes because wfParseUrl() returns false, which in turn is because PHP's built-in parse_url() returns false, which seems to be because it tries to interpret the ":0000" at the end as a port number and finds that invalid.
  • The subsequent edit is made, not modifying the bad link.
    • Again, the Parser's output includes the bad link in the ParserOutput metadata.
    • ConfirmEdit checks the externallinks table to find the existing links in the page. to detect whether any new links have been added in the edit being made. Since there's no externallinks entry for this bad link, it thinks it's new and so triggers a captcha.

And another one: I got a CAPTCHA (from a non-AC account) even for a null edit on Wikipedia:Teahouse until I made this change.