Last modified: 2011-01-25 00:29:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 8707 - Enable GlobalBlocking extension
Enable GlobalBlocking extension
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Extensions requests (Other open bugs)
unspecified
All All
: Highest minor with 49 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: crosswiki, schema-change, shell
: 8279 9527 11070 13612 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-19 18:28 UTC by Guillaume Paumier
Modified: 2011-01-25 00:29 UTC (History)
25 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Guillaume Paumier 2007-01-19 18:28:08 UTC
Hello,

We stewards and [[m:SWMT]] members regularly have to fight cross-wiki vandals
who vandalize a page and all the pages interwiki'd with it. Blocking the vandal
on one wiki is useless because he makes only one edit on each wiki: he
vandalizes the page and then proceeds to the next page in the interwiki list.
All we can do is follow him through interwikis and revert.

I'm only talking about IP vandals in this case, because such vandals don't
create accounts on each wiki they vandalize.

For the moment we haven't got any tool to deal with this kind of vandalism. A
kind of "meta-block" would be very useful.
Comment 1 Rob Church 2007-01-19 18:54:18 UTC
Marking this down as an extension request, because it requires a software change.
Comment 2 Thomas Goldammer 2007-01-19 21:01:17 UTC
But it would be very important. I don't know if it were the best if only stewards can block Wikimedia wide, but 
the feature is really neccessary.
Comment 3 Marco 2007-01-19 21:04:14 UTC
Should come with SUL, I think.
Comment 4 Rob Church 2007-01-19 21:12:21 UTC
(In reply to comment #3)
> Should come with SUL, I think.

It doesn't "come" with single user login, but it's made easier with single user
login, in that we'll have a global database to put this information in.

Single user login will not fix all of our problems; will people *stop* assuming
this, please?

(In reply to comment #2)
> But it would be very important. I don't know if it were the best if only
stewards can block Wikimedia wide, but 
> the feature is really neccessary.

How is what I said contradicting any claims that it would be useful
functionality? All I said was that we'd need software changes, which would
probably be best suited to an extension of some description.
Comment 5 Versageek 2007-01-19 21:28:46 UTC
It would also be helpful if it could be used in conjunction with [[m:WM:OP]]
Comment 6 Guillaume Paumier 2007-01-19 22:37:55 UTC
(In reply to comment #1)
> Marking this down as an extension request, because it requires a software change.

Thanks Rob for helping formatting this request.

(In reply to comment #2)
> But it would be very important. I don't know if it were the best if only
stewards can block Wikimedia wide, but 
> the feature is really neccessary.

If you support this request, please just vote for it, don't comment it;
Commenting sends an email to all people who are watching it.

(In reply to comment #5)
> It would also be helpful if it could be used in conjunction with [[m:WM:OP]]

This is a policy issue that has to be discussed with the whole Wikimedia
community; this bug is about the technical feature and its limited use for
blocking vandals temporarily.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-05-08 00:50:58 UTC
*** Bug 9527 has been marked as a duplicate of this bug. ***
Comment 8 Casey Brown 2007-06-04 00:25:36 UTC
Stewards wouldn't need to do this, come to think of it, it would be better to have a new permission assigned for it.  But that'll make some more work for people like Rob. :(  This might be lumped into the category of things done after SUL because it will be made easier that way. :(
Comment 9 Jon Harald Søby 2007-08-26 13:44:06 UTC
*** Bug 11070 has been marked as a duplicate of this bug. ***
Comment 10 Effeietsanders 2007-08-26 13:52:58 UTC
It would already be a huge iprovement to just be able to block IP-adresses wikimedia wide. In that case we at least dont have to wait for SUL to arrive. Thanks for considering. 
Comment 11 Casey Brown 2007-08-26 16:59:29 UTC
(In reply to comment #8)
> Stewards wouldn't need to do this, come to think of it, it would be better to
> have a new permission assigned for it.  But that'll make some more work for
> people like Rob. :(  This might be lumped into the category of things done
> after SUL because it will be made easier that way. :(
> 

emphasize need and could; stewards could still be a good group to have this permission. :-)
Comment 12 Angela 2007-09-09 18:08:40 UTC
Wikia's Regexblock could be used or adapted for this. http://www.mediawiki.org/wiki/Extension:RegexBlock

It allows a usergroup (like stewards) to block usernames and IPs across all (wikia) wikis.
Comment 13 Nobody 2007-10-06 04:08:21 UTC
Perhaps add it to the tools available on meta to admins there? Stewards have enough to do.
Comment 14 Effeietsanders 2007-10-06 07:50:04 UTC
No, meta-admins don't really have the back-up of an "interwiki" vote which the stewards do have. And this would not be something very work-intrensive, if worked out properly. 

I would btw most certainly appreciate it if someone with more knowledge of coding then me would like to take a look in Angela's remark and suggestion :) 
Comment 15 Herby 2007-10-06 12:50:28 UTC
Agreeing with Effeietsanders however I do spend quite a time on blocking open proxies on different wikis so this has been going through my mind.  I wonder if the blocking of open proxies only could be a meta admin task?  In practice they control cross wiki content in the shape of the interwiki map and the spam blacklist?  A thought? (And yes stewards to my mind have more important things to do)
Comment 16 Thomas Goldammer 2007-10-07 01:24:02 UTC
Hm, I personally think that any global task should in the first instance be a task for stewards (since they are the "global admins"). And they have to decide if they want to get this additional task or if they give it "down" to us Meta sysops. Grtx.
Comment 17 Casey Brown 2007-10-07 01:33:53 UTC
(In reply to comment #16)
> Hm, I personally think that any global task should in the first instance be a
> task for stewards (since they are the "global admins"). And they have to decide
> if they want to get this additional task or if they give it "down" to us Meta
> sysops. Grtx.

In that case, it could just be a separate right that all users in the stewards group got by default and can be given to another user by stewards.  (Like how all admins already have the ability to import page, but a steward can put a non-admin user into the "import" group and allow them to import pages.)
Comment 18 Larry Pieniazek 2007-10-12 16:03:48 UTC
At the cost of sending everyone yet another mail... (sorry). Can this be discussed somewhere else perhaps than in the bug list itself? I favour giving this (global IP blocking) as a separate permission, and giving it to stewards by default, and allowing stewards to decide if there are other people that should have it on a case by case basis. I think bringing this before the wider community for input would be goodness as there are some that might oppose it on grounds of it allowing one wiki to decide things for another, but by making it restricted to Stewards, who already have global trust, that might defuse that argument.
Comment 19 Casey Brown 2007-10-12 19:46:46 UTC
(In reply to comment #18)
> At the cost of sending everyone yet another mail... (sorry). Can this be
> discussed somewhere else perhaps than in the bug list itself? I favour giving
> this (global IP blocking) as a separate permission, and giving it to stewards
> by default, and allowing stewards to decide if there are other people that
> should have it on a case by case basis. I think bringing this before the wider
> community for input would be goodness as there are some that might oppose it on
> grounds of it allowing one wiki to decide things for another, but by making it
> restricted to Stewards, who already have global trust, that might defuse that
> argument.

Someone wants a new extension; this is the proper place to request that.  Who should give and get this right, that is something that will be brought up elsewhere after the technical capability is created.
Comment 20 Herby 2007-10-28 11:22:52 UTC
I realise it won't necessarily move things any faster but currently there are vandal bots operating cross wiki from Open proxies.  I've now seen that on Meta, Commons, en wb, en wq & en wp creating or blanking to leave random letters.  I've probably blocked at least 50 in the past week - I think around 10 have been active on en wp over the past 12 hours for example.  That would have been SO much more effective if it had applied cross wiki. - H
Comment 21 Yann Forget 2007-10-29 14:13:06 UTC
Hello,

I think this bug is very important. Thanks, Yann
Comment 22 Casey Brown 2007-10-29 20:01:38 UTC
(In reply to comment #21)
> Hello,
> 
> I think this bug is very important. Thanks, Yann
> 

Have you considered voting for it? http://bugzilla.wikimedia.org/votes.cgi?action=show_user&bug_id=8707#vote_8707
Comment 23 Pedro Sánchez 2007-10-29 20:55:14 UTC
Yet more mixed messages.
Some said we should votes to make devs notice.
then I was told by some dev, that they don't really pay attention to votes
Some devs say "hey, please remind us on IRC otherwise your bugs go unnoticed"
others, when reminded on IRC get annoyed "leave us, we have stuff to do!"

I've resorted for now to semi-automate blocking so it's easier for me to block on many wikis than relying on this
Comment 24 Leon Planken 2007-10-29 23:23:23 UTC
I have taken a look at the source code of the RegexBlock extension ( http://www.mediawiki.org/wiki/Extension:RegexBlock ) and to my inexperienced (*) eyes, it looks good; I believe it can be used for this purpose.

Things I noticed:
- $wgContactLink should be set to some wikimedia-specific contact information, since the default in regexBlock.php is wikia-specific;
- $wgGroupPermissions must be set correctly so that stewards on meta can use this extension; the default setting in SpecialRegexBlock.php is "$wgGroupPermissions['staff']['regexblock'] = true". I'm not sure whether this is correct.

(*) The extent of my experience is that I once wrote a patch for bug 3270.
Comment 25 Nobody 2007-10-31 17:29:47 UTC
(In reply to comment #24)
> I have taken a look at the source code of the RegexBlock extension (
> http://www.mediawiki.org/wiki/Extension:RegexBlock ) and to my inexperienced
> (*) eyes, it looks good; I believe it can be used for this purpose.
> 
> Things I noticed:
> - $wgContactLink should be set to some wikimedia-specific contact information,
> since the default in regexBlock.php is wikia-specific;
> - $wgGroupPermissions must be set correctly so that stewards on meta can use
> this extension; the default setting in SpecialRegexBlock.php is
> "$wgGroupPermissions['staff']['regexblock'] = true". I'm not sure whether this
> is correct.
> 
> (*) The extent of my experience is that I once wrote a patch for bug 3270.
> 

So, either duplicate the line (if you have staff & stewards) or modify it (if not)
and change the text "staff" to "steward". Done, ne? I seem to recall it being
mentioned that stewards are on a special extension, but as the group is publicly
viewable, I don't see that other extensions shouldn't be able to make use of the
rights group.
Comment 26 Meno25 2007-11-30 02:31:13 UTC
Isn't this bug duplicate of Bug 8279?
Comment 27 Effeietsanders 2007-11-30 07:36:47 UTC
*** Bug 8279 has been marked as a duplicate of this bug. ***
Comment 28 SJ 2007-12-24 01:42:57 UTC
This bug has had 3-4 duplicate filings, and is increasing in opportunity cost as the # of wikis grows... RegexBlock looks handy.  <adds a vote for the bug>

I changed this to a minor bug, from merely an enhancement, because while a particular implementation is an enhancement request, vandal blocking suffers fromt he bug that that there is no way to say "this IP should be blocked across all current and future sister wikis [for <period of time>]," which is often the core intent behind blocking.  

Indeed, we might want to set up some sort of global IP graylist similar to our shared URL blacklist and shared interwiki list : IPs that regularly vandalize or massively spam wikis, which [new wikis] should beware.
Comment 29 とある白い猫 2007-12-24 12:14:27 UTC
I like your idea. A meta page or two could deal with the issue just like how the spam list works.

Also, certain ranges also should be blocked from editing the smaller wikis (wikis without admins) seperately.
Comment 30 とある白い猫 2007-12-24 12:18:33 UTC
Isn't this bug duplicate of Bug 8279? 8279 < 8707
Comment 31 Casey Brown 2007-12-24 13:48:41 UTC
(In reply to comment #30)
> Isn't this bug duplicate of Bug 8279? 8279 < 8707
> 

Probably, but this bug has a lot more discussion and would probably be more useful if a developer decided to try and fix the bug.
Comment 32 Victor Vasiliev 2008-02-11 15:44:19 UTC
Global blocking != crosswiki blocking (see bug 12987 for the last one)
Comment 33 oysterguitarist 2008-02-27 05:11:22 UTC
*** Bug 12987 has been marked as a duplicate of this bug. ***
Comment 34 Jesse (Pathoschild) 2008-02-27 08:26:11 UTC
(...and bug 12987 has been unmarked as a duplicate.)
Comment 35 Andrew Garrett 2008-04-03 10:31:18 UTC
This is half done. I'm working on it.
Comment 36 Raimond Spekking 2008-04-04 07:59:52 UTC
*** Bug 13612 has been marked as a duplicate of this bug. ***
Comment 37 Andrew Garrett 2008-04-07 09:17:30 UTC
Now exists as the GlobalBlocking extension.

Leaving this bug open, pending the extension being enabled on Wikimedia projects.
Comment 38 Mike.lifeguard 2008-04-15 01:45:15 UTC
Frankly, not having a way to unblock on a per-wiki basis is a show-stopper for me. That's like having a global spam blacklist with no ability to override with a local spam whitelist -- only worse because this is blocking users, not simply disallowing certain urls. I appreciate the work you've put into this, but until local unblocking is possible, the extension is not finished.
Comment 39 MF-Warburg 2008-04-15 13:22:11 UTC
But why would you want to unblock someone who is blocked globally? The extension should of course only be used for vandals hitting many wikis; and it is very unlikely that someone vandalizes many wikis except one where he does useful work. Even if that happens, the account should be blocked globally nevertheless because the vandal can of course start vandalizing the wiki where he's not blocked at any moment.
Comment 40 Cary Bass 2008-04-15 15:41:06 UTC
Given the types of blocks that global blocking necessitates, it is meaningless to have local unblock.  We're talking about pure cross-wiki vandals and spammers.  Community bans are that...community bans--and are on a local wiki basis; these things would not be subject to global blocking.
Comment 41 Andrew Garrett 2008-04-15 16:09:04 UTC
Discussion as to this extension's application on Wikimedia is ongoing at http://meta.wikimedia.org/wiki/Global_blocking
Comment 42 Cometstyles 2008-05-14 04:27:07 UTC
If this bug ever gets implemented, could the devs make sure that the Global block doesn't apply to Meta so that if the IP blocked through this can fight their case on Meta if they were blocked wrongfully. 
Comment 43 とある白い猫 2008-05-18 07:01:47 UTC
I think the global blocker should be granted certain types. Unblocking should be done centrally not locally.

There are very good reasons to block open proxies on all wikis with of course exceptions. We have a good idea which wikis want to allow open proxies and which ones do not.

Asking Chinese wikipedia to regularly unblock open proxies that were centrally blocked doesn't seem like the right thing to do...

I would recommend a spam autoblocker-like system.
Comment 44 とある白い猫 2008-05-18 07:07:06 UTC
In reply to Comment #4, will SUL solve global warming?
Comment 45 Casey Brown 2008-05-18 18:09:29 UTC
(Fixing title change by White Cat, this is about the Global*Blocking* extension: <http://www.mediawiki.org/wiki/Extension:GlobalBlocking>)
Comment 46 Cometstyles 2008-05-20 10:25:21 UTC
I hope this gets done really fast due to an increase in XRumer bots operating through open proxies attacking small wikis mainly and we have about 20 attacks an hour nowadays :(
Comment 47 Brion Vibber 2008-05-20 21:17:17 UTC
Please report such attacks to us so we can block them on a much more useful level (based on content).
Comment 48 Thomas Goldammer 2008-05-20 22:26:02 UTC
(In reply to comment #47)
These attacks occur frequently (basically every day), multiple IPs are used (changing at every edit, but most IPs are returning randomly later), and not all are open proxies (though most are). I guess you all would not get to other work if we bothered you all the time with blocking these IPs. It would just save a lot of our and your time if global IP block were finally enabled...

Thanks, Th.
Comment 49 Brion Vibber 2008-05-20 22:36:27 UTC
There is little to no benefit to attempting to block IPs in this sort of case, which is why I recommend blocking behavior patterns, which is why I'm recommending that you not be secretive about it.
Comment 50 Casey Brown 2008-05-20 22:41:22 UTC
(In reply to comment #49)
> which is why I'm recommending that you not be secretive about it.

Sorry, but what exactly is secretive here?

Comment 51 Cometstyles 2008-05-21 05:02:44 UTC
Nothing secretive about it, see the devs own Mediawiki.org for example, these are some of the edits:

* http://www.mediawiki.org/w/index.php?title=Extension:MediaWiki_Bulletin_Board&diff=prev&oldid=188045
* http://www.mediawiki.org/w/index.php?title=Manual:Short_URL&diff=prev&oldid=188042
* http://www.mediawiki.org/w/index.php?title=Manual:Short_URL&diff=prev&oldid=188042
* http://www.mediawiki.org/w/index.php?title=Manual:Interface/Sidebar&diff=prev&oldid=188031

The first four above are the common ones used by older types of XRumer bots which blanks a portion of the article and adds stuff like "good work man", "nice site dude" etc and another type is :

* http://www.mediawiki.org/w/index.php?title=Help:Talk_pages&diff=prev&oldid=187691
* http://co.wikipedia.org/w/index.php?title=MediaWiki+talk%3ANewpage&action=history
* http://cy.wiktionary.org/w/index.php?title=Sgwrs+MediaWici%3ANewpages&action=history

It add random characters to the article or creates new pages on MediaWiki talk pages.
Comment 52 Brion Vibber 2008-05-22 22:51:10 UTC
(Above-mentioned spam issues are being investigated and dealt with separately.)

Now, back to the actual code review!

Issues that need to be addressed...

GlobalBlocking class..

	GlobalBlocking::getUserPermissionsErrors
		lack of caching may or may not be worrying

		conditions...
			$conds = array( 'gb_address' => $ip, 'gb_timestamp<'.$dbr->addQuotes($dbr->timestamp(wfTimestampNow())) );
			ok that looks totally broken.
				1) no ip range checks
				2) timestamp in the past? wtf? we want future blocks?
			-> add the range checks
			-> remove this extra timestamp check
			-> add an expiry check

		$expiry changes data types (coded timestamp -> text), this is poor practice
			-> change this to another var

		expiry is loaded but not checked
			> expire if we're old!

		$block->gb_by_wiki is dumped straight into err msg output without a clear data type
			> what's the type of db_by_wiki? dbname or interwiki?

	GlobalBlocking::getGlobalBlockingMaster()
	GlobalBlocking::getGlobalBlockingSlave()
		-> uses wfGetDB... is this right for the current load balancer system?

	GlobalBlocking::buildForm
		-> just replace this with wfBuildForm() since it calls through...

SpecialGlobalBlock...

	SpecialGlobalBlock::execute
		if (!is_array($errors) || count($errors)>0) {
			wtf? this is some ugly damn code. :D
			ends up overall just looking very confusing
			-> pull apart this if() tree to something legible

	SpecialGlobalBlock::loadParameters()
		-> use getText() for reason
		-> quote wpExpiryOther

	SpecialGlobalBlock::trySubmit()
		Error-out for dupe blocks is done before expired blocks are purged.
		-> purge expired blocks at top
		-> range blocks are not saved properly -- missing range start and end fields
		expiry handling... shouldn't this be encapsulated for us already?
			-> check Block for encapsulated infinity handling
	
	SpecialGlobalBlock::buildExpirySelector
		doesn't this duplicate existing code?
			-> find and replace with clean call to core code

	SpecialGlobalBlock::buildForm
		-> inputs are too short (compare to 45 chars on Special:Blockip)
		-> labels aren't aligned properly

SpecialGlobalBlockList

	SpecialGlobalBlockList::showList
		-> bad escaping on error messages -- use wfEscapeWikiText() or don't run these through wiki parser

		validity checks are overlong
			-> use IP::isIPAddress

	SpecialGlobalBlockList::unblockForm
		-> same bad escaping on error messages

	SpecialGlobalBlockList::tryUnblockSubmit
		-> overload IP checks again

I've seen this pattern many times over:
		$expiry = Block::decodeExpiry( $row->gb_expiry );
		if ($expiry == 'infinity') {
			$expiry = wfMsg( 'infiniteblock' );
		} else {
			global $wgLang;
			$expiry = $wgLang->timeanddate( wfTimestamp( TS_MW, $expiry ), true );
		}

This is probably already encapsulated somewhere in Block-land. If it's not, at least make a local func for it!

	GlobalBlockListPager::formatRow
		Comments are getting formatted with the regular wiki parser. This can be very disruptive -- images, tables, broken code...
		-> use the comment parser, like all other comments in such lists

Comment 53 Andrew Garrett 2008-05-24 12:15:10 UTC
Most of this addressed in r35272.

Some notes:
* Yes, wfGetDB works with the current load balancer. wfGetDB is a shortcut for the longer notation used in the CentralAuth functions.
* buildExpirySelector does not duplicate core code, but I am happy to generalise it and move it into core (a la buildForm).
Comment 54 Andrew Garrett 2008-06-15 04:38:35 UTC
Has this been looked at again, yet?
Comment 55 Cometstyles 2008-06-21 03:14:48 UTC
Could this be re-looked at please, there has been many Global accounts created in the last couple of weeks and locking them globally doesn't really help, we need to block it completely (http://meta.wikimedia.org/wiki/Special:Log/globalauth), could this extension use be given to the Stewards as soon as possible ..thanks
Comment 56 Cometstyles 2008-07-11 13:11:44 UTC
I believe all this Bug needs is approval from Mr B and we are all set to go, so Mr Brion I hope you can give this extension a test and enable it for the stewards please since we discussed this with the steward on IRC and they could really use this extension, and they really can't go around wikis deleting multiple spam or temporarily adding spamlinks to the Spam blacklist.. :)
Comment 57 Cary Bass 2008-07-31 00:01:54 UTC
What?  This hasn't been done yet?  Darn, this would go a long way toward helping us defeat certain particularly ugly cross-wiki vandals once and for all.  There's a lot of steward and checkuser time going to this right now, and if we had global blocking, it would effectively put this under control and our volunteers could work on more productive things!
Comment 58 Brion Vibber 2008-08-04 01:46:26 UTC
Will peek at this shortly...
Comment 59 Brion Vibber 2008-08-10 21:59:23 UTC
I've fixed up some basic breakage:

* Failure to display the error messages on block for submission (eg for invalid expiry format)
* Total breakage of expiry input
* Total breakage of expiry on output
* PHP warnings spewed out in many places
* Utter weirdness in permission checks

I have some general recommendations I'd like to see fixed up:

The schema uses lots of TINYBLOB fields, this seems rather odd -- recommend changing to regular VARCHARs here with sensible sizes. I'm not sure how properly tinyblobs are indexed.

The special page forms are pretty confusing, and don't link together very clearly. It's hard to get back to the block form from the list, and it's hard to cleanly refresh the list after doing anything -- several forms seem to be bundled together into the list, and there's a lot of POST requests going around with no parameters on the URL.

I'd recommend breaking the additional two forms out and using clean GET urls on the block list.

There also doesn't seem to be a drop-down list for the expiry, which also means there's no default and no sample values, which is really a pain in the butt. There's some infrastructure for a drop-down, but it doesn't work since the options list defaults to empty. This makes NO sense -- we already have a perfectly good list of block expiry options in the base wiki, why not use it here?

This message looks awkwardly formatted:
	'globalblocking-block-errors' => "The block was unsuccessful, because: \n$1",

Generally I'd recommend keeping a block-level intro separate from the following list(s) of data, as it's easier to maintain.
Comment 60 Andrew Garrett 2008-08-11 10:28:09 UTC
(In reply to comment #59)

This has all been fixed up. I also did a full test and went over the code, since I wrote it back in March (and it was one of my earlier extensions from scratch), and found a few more glaring bugs.

See r39129 for details.


Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links