Page MenuHomePhabricator

AbuseFilter should allow storing regex matches into variables
Closed, DuplicatePublic

Description

The motivation for this request is the following task:

A user creates a named reference (e.g. <ref name="something">...</ref>) and uses it throughout a page (e.g. <ref name="something"/> ...). Later, another user edits the page, and removes the first definition of that named reference. This causes all subsequent uses to return an error.

The idea is to create an abuse filter that can (a) detect when a named reference is removed, (b) detect that value of the "name" parameter of that reference, and (c) check to see if any other reference tags using the same name parameter exist throughout the page.

Parts a and c are very easy. Part b is only possible if you can store the output of a regular expression match into a variable. Currently, the only regex function allowed by AbuseFilter is rcount, which doesn't serve this purpose.

See Also:

Details

Reference
bz66032

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:24 AM
bzimport added a project: AbuseFilter.
bzimport set Reference to bz66032.
bzimport added a subscriber: Unknown Object (MLST).

In some of our (zhwiki) filters, I use something like:

(removed_lines + 'UNIQUE_STRING' + new_wikitext) rlike '<ref name="([^"]+)">.*UNIQUE_STRING.*<ref name="\1"/>'

Thanks; while I am trying to get that to work, I still want to point out that this method can only pass the matches to the next part of the same regex (i.e. \1 only works within the context of the same rlike function). Ideally, one should be able to start \1 into a variable and then use that variable in a subsequent line of code.

(In reply to Huji from comment #2)

Thanks; while I am trying to get that to work, I still want to point out
that this method can only pass the matches to the next part of the same
regex (i.e. \1 only works within the context of the same rlike function).
Ideally, one should be able to start \1 into a variable and then use that
variable in a subsequent line of code.

Yeah but normally this trick works everywhere where the variable is used a next regex match, because you can always concatenate other variables together and use a big regex to match that long string, like what's done above.

I think what liangent provided above solves my particular use case