Task #54365


Added by Chris topher almost 6 years ago. Updated over 3 years ago.

Should have
Start date:
Due date:
% Done:



Currently not a problem, but some thoughts are in #53726:

Basic idea could be:
  • Block a user on typo3.org
  • During SSO login transfer the information if the user is blocked to the wiki (exactly as is already done with the user groups)
    • If the user is blocked, do one or two API calls and he is blocked in the wiki as well. It only needs to transfer the information, whether the user is blocked on t3o; blocking in the wiki itself can then happen automatically and would not cause any work.
  • Another idea would be: Transfer the information if the user is blocked and if so, just do not log him in. As simple as that; with our current setup that will also prevent him from writing stuff in the wiki.
    • The easiest solution would probably be not to prevent this problem in the wiki, but already one step before that, on typo3.org. The user should just be blocked there and before any login would be triggered. This has the advantage that code for that is only needed at one place, that is on typo3.org and not in every single site, which is connected. That way blocked users will also be unable to use SSO in order to log in to the connected sites/to all connected sites.


#1 Updated by Chris topher over 3 years ago

The index_sso.php script should get the information, whether a user currently is disabled.

Then if the user does not exist, if he is blocked, just do not create a new user. Just do nothing and die().
If the user does exist, in the block of code, where the user account is updated, block it like so
(based on https://github.com/wikimedia/mediawiki-extensions-BlockAndNuke/blob/master/BanPests.php#L130):

require_once "includes/Block.php"; // Check, if the user _is already_ blocked in MediaWiki. Do not add a block, if there is already one. if( !Block::newFromTarget( $user->getName() ) ) { // If the user is not yet blocked, block him. // For parameters see the comment of Block::insert, // https://github.com/wikimedia/mediawiki/blob/31d4359b45a4a8d7174753ba90ee33de685160cb/includes/Block.php#L451 and // https://www.mediawiki.org/wiki/Manual:Ipblocks_table $block = new Block( array( 'address' => $user->getName(), // Name of the user to be blocked 'user' => $user->getID(), // User ID to be blocked 'by' => $banningUser->getID(), // User ID of the administrator who made the block; maybe use the ID of a user like "Maintenance script" or so. // MediaWiki should retrieve the associated username automatically. 'reason' => 'Blocked on the typo3.org mainsite.', // wfMessage( 'blockandnuke-message' )->text(), 'expiry' => wfGetDB( DB_SLAVE )->getInfinity(), // Should result in the string "infinity" to make an infinite block 'createAccount' => true, // Also block from creating accounts? 'blockEmail' => true // Block him from writing e-mails via MediaWiki? ) ); // Additionally set an autoblock on the IP address; time for this block is $wgAutoblockExpiry, which defaults to 86400 seconds = 1 day. // If one account of a spamming IP has been blocked, then this will also block following accounts from that IP while that block is active. // Great means against spammers, who create tons of accounts. $block->isAutoBlocking( true ); // Add the block to the database. if($ret = $block->insert()) { /* Check, if the MediaWiki interface still shows a user as blocked, if there "only" is the actual block from table ipblocks. This block entry in the table ipblocks should actually be enough. Should that not be the case, e.g. on the user page or on the Contributions page, then add an according entry to the log. $log = new LogPage('block'); $log->addEntry('block', Title::makeTitle( NS_USER, $user->getName() ), 'Blocked through typo3.org', array('infinite', $user->getName(), 'nocreate')); */ } }

The even better idea might be to get the information if a user is blocked from typo3.org and, if so, to die() in index_sso.php before login/registration is actually being done.

Also available in: Atom PDF