Last modified: 2013-08-07 10:27:35 UTC
To be enabled on the global scale, the AbuseFilter would require a variable which identifies which project the filter is acting on, in the same way that article_text identifies a page. project_prefix rlike "en", as a very basic example.
*** Bug 41524 has been marked as a duplicate of this bug. ***
The use of CentralAuth wikisets would be ideal, in addition to this variable. People wouldn't have to view a private filter just to see what wikis it applies on.
The use of CentralAuth wikisets would make this entire proposal moot. These filters need to be able to act where they need to and when, and a variable in a filter would be indefinitely easier to set up than this. Better to focus on something which can be done with relative ease (I hope) than linking the global abusefilter to another already broken extension.
Well, AbuseFilter could also use its own wikisets filter, but a variable simply won't do for this purpose because it would mask which projects a filter affects for private global filters. A variable would also be an unnecessary consumer of the condition limit.
Would a wiki_id variable ($wgDBname-$wgDBprefix or just $wgDBname if prefix isn't set) be okay? I noticed in your example you said rlike "en" - so maybe you want the content language instead?
Well, a variable of any sort is probably unsuited for this purpose per my previous comments.
wiki_id would be great, I should have used something like "en_wiki/en_quote" in the example rather than "en". The entire point of a private filter is to hide that information. The issues with the current spam fighting techniques is that they are so open that people can easily evade them. The point here it to introduce a system which prevents that, while maintaining transparency as required.
It'll be something like "enwiki", "dewikiquote", etc. Gerrit change #31007
Ajraddatz: you haven't addressed my other concerns - the condition limit.
Apologies, didn't see that. The idea isn't to have a filter acting on half of Wikimedia's projects, but rather for it to either act on a large group or a small group. I'm hoping that condition limits won't be too restricting, but if they turn out to be, then your idea would certainly help. As I think I said on IRC, tying it in with CentralAuth wouldn't be a bad thing - just not something we should be focussing on right now.
It really CAN add up to a lot of coding in a filter just to choose a wiki. For example, just excluding non-GS wikis would involve around 20 checks for the value of wiki_id.
I've abandoned the wiki_id changeset because I think it's going to attract conditional spam. I was talking to Werdna and Csteipp in #mediawiki earlier, and the idea came up to: * Add a hook to AbuseFilter so other extensions can add variables. * Hook this in CentralAuth to give a variable containing a list of wiki sets which apply to the current wiki. I then mentioned Jasper's comment in bug 41524 about sometimes only applying to a certain language - Chris said that having a wiki_id variable would work, you could just limit to a language with regex.
If this could be hooked to centralauth wikisets, that would work too.
Any updates on the progress of this? Times like these that I wish I could code well.
I'm not sure this is a good idea as the way CentralAuth currently implements wikisets might not scale well with many different wikisets for different filters (they are saved as comma separated database lists). Maybe we should hack (fast and well scaling) wikisets to AF itself? (The alternative of hacking CentralAuth wiki sets to be faster is ugly but doable as well)
Wikisets in AF seems redundant, but if that is the easiest way then go right ahead! Is there any way that I could prioritize this more, other than just changing one of the dropdowns to a higher priority above? This is something which is needed at the global level, so the sooner this gets rolled out the better. If there is anything that I can do, I'd be glad to do it, but I unfortunately am not good at the coding.
Ajraddatz: I don't think there's much to do except for asking maintainers / previous AF developers...
Chris Steipp has uploaded Gerrit change #42565 which adds a CentralAuth WikiSets variable to AbuseFilter.
(In reply to comment #18) > Chris Steipp has uploaded Gerrit change #42565 which adds a CentralAuth > WikiSets > variable to AbuseFilter. Which has now been resubmitted as Gerrit change #42800. Also moving this to the CenralAuth component.
Change 42800 abandoned by Hoo man: (bug 41172) Add Wikiset as AbuseFilter variable Reason: per DevCamp https://gerrit.wikimedia.org/r/42800
We don't want to do this, we rather want to have an own interface in AbuseFilter which will allow local administrators to disable global filters (for the local wiki).
