robchur wrote:

Marking this down as an extension request, because it requires a software change.

thogol wrote:

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.

marco wrote:

Should come with SUL, I think.

robchur wrote:

(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.

wiki wrote:

It would also be helpful if it could be used in conjunction with [[m:WM:OP]]

(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.

ayg wrote:

*** Bug 9527 has been marked as a duplicate of this bug. ***

bugs wrote:

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. :(

• Bug 11070 has been marked as a duplicate of this bug. ***

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.

bugs wrote:

(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. :-)

beesley wrote:

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.

lilewyn wrote:

Perhaps add it to the tools available on meta to admins there? Stewards have enough to do.

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 :)

herbythyme wrote:

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)

thogol wrote:

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.

bugs wrote:

(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.)

lar wrote:

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.

bugs wrote:

(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.

herbythyme wrote:

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

Hello,

I think this bug is very important. Thanks, Yann

bugs wrote:

(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

pdsanchez wrote:

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

bugzilla.wikimedia wrote:

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.

lilewyn wrote:

(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.

Isn't this bug duplicate of Bug 8279?

• Bug 8279 has been marked as a duplicate of this bug. ***

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.

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.

Isn't this bug duplicate of Bug 8279? 8279 < 8707

bugs wrote:

(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.

Global blocking != crosswiki blocking (see bug 12987 for the last one)

oysterguitarist wrote:

*** Bug 12987 has been marked as a duplicate of this bug. ***

(...and bug 12987 has been unmarked as a duplicate.)

This is half done. I'm working on it.

• Bug 13612 has been marked as a duplicate of this bug. ***

Now exists as the GlobalBlocking extension.

Leaving this bug open, pending the extension being enabled on Wikimedia projects.

mike.lifeguard+bugs wrote:

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.

triyork wrote:

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.

bastique.bz wrote:

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.

Discussion as to this extension's application on Wikimedia is ongoing at http://meta.wikimedia.org/wiki/Global_blocking

cometstyles wrote:

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.

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.

In reply to Comment #4, will SUL solve global warming?

bugs wrote:

(Fixing title change by White Cat, this is about the Global*Blocking* extension: http://www.mediawiki.org/wiki/Extension:GlobalBlocking)

cometstyles wrote:

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 :(

Please report such attacks to us so we can block them on a much more useful level (based on content).

thogol wrote:

(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.

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.

bugs wrote:

(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?

cometstyles wrote:

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.

(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

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).

Has this been looked at again, yet?

cometstyles wrote:

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

cometstyles wrote:

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.. :)

bastique.bz wrote:

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!

Will peek at this shortly...

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.

(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.