This changes SpamBlacklist to make use of the new, ContentHandler
aware hooks.
This change also includes some refactoring and cleanup which made
the migration to the new hooks easier.
Change-Id: I21e9cc8479f2b95fb53c502f6e279c8a1ea378a5
The default blacklist was no longer being used, because the line
$wgSpamBlacklistFiles =& $wgBlacklistSettings['spam']['files']
initialized $wgBlacklistSettings['spam']['files'] to null,
and BaseBlacklist::__construct then overrode $this->files
with null.
Change-Id: I22448bfb87eef6dd86b61362f3eb6bb2198a10b6
Adds a logBlacklistHit function function, which is callend whenver a new url
matches the blacklist. A new log type of "spamblacklist" is created, and is only
viewable by people with the "spamblacklistlog" userright. This is given to sysops
by default.
By default this is disabled, and is controlled by $wgLogSpamBlacklistHits.
Bug: 1542
Change-Id: I7b1ee2b3bb02b693d695bf66d157e2c33526c919
Currently if a rule says "go.gle" and http://www.google.com/ is being
added, "http://www.google" is displayed as the blocked part. This
doesn't look quite nice. Now it just displays "google".
Change-Id: I0851c00d38129a8e9910c65100998eb3f1e5b2c2
provide all blocked URLs").
SpamBlacklist extension to provide all matched URLs to
spamPageWithContent() rather than just one. Performance
hit negligible and zero for all edits that don't hit the
SpamBlacklist (99.999%+).
DEPENDENT ON OTHER HALF OF FIX (now in core):
https://gerrit.wikimedia.org/r/3740
Change-Id: Ia951d5795c5cedb6c3876be89f8a08f110004102
* SpamBlacklist: code is weird but I'm pretty sure this needs HTTP
* ContributionTracking: expand return URL to current protocol. Use HTTP in the test suite (PROTO_CURRENT makes no sense in tests since they run from the command line)
* GlobalUsage: remove URL expansion, not needed after r95651
* CentralNotice: expand URL because it gets fed to window.location indirectly via JS
* OpenSearhXml: use canonical URLs in XML output
* MobileFrontend: expand a URL that's used in a Location: header
Bug comment: Set PCRE_MULTILINE on spamblacklist regexes. $ on spam blacklist regex should match the end of the url (not of the text) so it can be used to match only the mainpage. Since the candidate urls are already joined with a new-line separator, it's just setting PCRE_MULTILINE on the regex.
An API edit attempt with Spam Blacklist firing will now output something instead of crashing:
<?xml version="1.0"?><api><edit spamblacklist="http://blacklistme.example.com"
result="Failure" /></api>
Lines with "\" at the end would silently break both that and the following line in the batch, without triggering the overall parse errors.
Added a specific check for this case to skip the bad lines when building, and to check for them and report a warning during editing.
function_exists( 'Http::get' ) always returns false, since that's not a function name.
If the current state of the extension only works on modern versions of MW, then just call Http::get() without checking. If it still works on versions that predate it, it's best to keep the existing compat code probably.
* Use the new EditFilterMerged hook if available, for faster link finding
* Random bits of code were leaking out of the body file into the loader, poked them back in.
* Handle bad regexes more gracefully:
- The batched regexes are tested for validity, and if one is bad, the lines from that source are broken out line-by-line. This is slower, but the other lines in that source will still be applied correctly.
- Suppress warnings and be more verbose in the debug log.
- Check for bad regexes when a local blacklist page is edited, and prompt the user to fix the bad lines.
* Caching issues:
- Cache the full regexes per-DB instead of per-site; this should be friendlier to shared environments where not every wiki has the same configuration.
- Hopefully improve the recaching of local pages, which looked like it would preemptively apply the being-edited text to the cache during the filter callback, even though something else might stop the page from being saved. Now just clearing the cache after save is complete, letting it re-load later.
* Split out some of the regex batch functions for clarity.
There are probably still issues with caching of HTTP bits, and in general the local DB loading looks verrrry fragile.
Test this a bit more before syncing. :)
Should save some trouble for annoyed people. :)
The regular message cache behavior is used for this message, so it'll also update immediately, without waiting for the shared caches to time out.
Additionally, added a fix for configurations which don't hardcode the PHP include_path by using $IP in an include for HttpFunctions.php.
