Extension:SimpleSecurity

This code exhibits voodoo programming techniques. The most common of these is extending an instance's class at runtime after it has been instantiated, a technique that can be used to provide additional hooks into existing code without requiring modification of code-base files. For a list of all our scripts which exhibit voodoo, see Category:Code that uses voodoo.

This code is in our Git repository here. Note: If there is no information in this page about this code and it's a MediaWiki extension, there may be something at mediawiki.org.

SimpleSecurity 4.x incompatible with MediaWiki 1.17+

An issue has cropped up with MediaWiki 1.17 (bug 29525) which is due to changes in the load-balancer that are incompatible with the DatabaseHook used in SimpleSecurity.

PHP Fatal error: Call to a member function isOpen() on a non-object in LoadBalancer.php on line 652

The cause

This is due to the following statement returning null (in MediaWiki 1.18 this method is changed to DatabaseBase::factory(), but the same problem persists),

{{{1}}}

SimpleSecurity changes the database-type to "SimpleSecurity" which is a new type that extends the original type by replicating it exactly but adding the hooks into the query() and fetchObject() methods. The problem is that the newFromType() and factory() methods use a hard-coded list of available types and return null if the passed type doesn't match any of them,

{{{1}}}

Updating the code to make this list globally accessible would be quite simple, but would not be introduced until probably version 1.19, so there would then be two major versions of MediaWiki in use which are incompatible with SimpleSecurity, so we need to figure out a new approach to the DatabaseHook which works with the latest LoadBalancer.

Finding a solution

The bottom line is that we need the wfGetDB() global function to return an instance of database class that has been extended by having our hooks added into the query() and fetchObject() methods. As can be seen in the following snippet from GlobalFunctions.php showing the content of the wfGetDB() function, we actually need to be looking at LBFactory::singleton(),

{{{1}}}

Here's the content of LBFactory::singleton() which simply checks if a single instance of the LBFactory exists, and creates one if not. It uses the $wgLBFactoryConf global array to select the class to be used for this singleton instance,

{{{1}}}

In DefaultSettings.php we see that the $wgLBFactoryConf global sets the default LBFactory class to LBFactory_Simple with no other paramaters apart from the type of class (i.e. nothing else is sent to the LBFactory_Simple constructor),

{{{1}}}

The constructor creates a new ChronologyProtector for the singleton which sits idle until getMainLB() is called (which the wfGetLB() global function does), and the first thing getMainLB() does if nothing exists yet is to call newMainLB(),

{{{1}}}

It's the LoadBalancer class that contains the call to DatabaseBase::newFromType()/factory() in its reallyOpenConnection() method which contains the prolematic hard-coded list of available database classes, so the easiest fix would be to adjust the voodoo to change the reallyOpenConnection() so that it handles the creation of the instance itself without performing the check rather than delegating it to the DatabaseBase class.