Last modified: 2014-09-23 19:31:01 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 38907 - IP Block query fails with External auth
IP Block query fails with External auth
Product: MediaWiki extensions
Classification: Unclassified
Other (Other open bugs)
All All
: Normal normal (vote)
: Future release
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2012-08-01 05:00 UTC by Steve Walsh
Modified: 2014-09-23 19:31 UTC (History)
3 users (show)

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

Authplugin that references conference management system DB (9.08 KB, application/x-httpd-php)
2012-08-01 05:00 UTC, Steve Walsh

Description Steve Walsh 2012-08-01 05:00:10 UTC
Created attachment 10914 [details]
Authplugin that references conference management system DB

We have an authplugin that has been used for several years to tie a conference management system and mediawiki together for similar sign-on . This year, we've deviated from the norm and used MediaWiki-1.19.1 (previous years have used the Debian packaged version), and we seem to be hitting a problem with the IP Block check query. 

Both the conference management system and mediawiki are running on (separate) pgsql databases. We have one user in the database, being the local user created at install time, but when they attempt to log in (with the plugin enabled), we hit the following SQL error;

Query confwiki (18) (slave): SELECT /* User::idFromName */  user_id  FROM "mwuser"  WHERE user_name = 'Lca2013'  LIMIT 1  
User::getBlockedStatus: checking...
Query confwiki (19) (slave): SELECT /* Block::newLoad */  *  FROM "ipblocks"  WHERE ipb_address IN ('20215822143','20215822143')  OR ((ipb_range_start  LIKE '%' ) AND (ipb_range_start <= 0) AND (ipb_range_end >= 0))  
SQL ERROR: ERROR:  operator does not exist: text <= integer
LINE 1: ...(ipb_range_start  LIKE '%' ) AND (ipb_range_start <= 0) AND ...
HINT:  No operator matches the given name and argument type(s). You might need to add explicit type casts.

All further queries in this transaction return the error "SQL ERROR (ignored): ERROR:  current transaction is aborted, commands ignored until end of transaction block"

This query run in pgsql fails with the same error.

Disabling the external auth plugin solves the problem, but to the point where we can't even see the above query being run in debug, so we're not sure quite what's happening here, or if the external authplugin just happens to trigger an edgecase not yet found. 

Reading the authplugin docs doesn't show anything needed in an authplugin to make the ipblock side of things work.

Changes to the LocalSettings.php are;

$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;

$wgFileExtensions = array_merge( $wgFileExtensions, array( 'pdf', 'ppt' , 'odt', 'odf', 'odp', 'otp') );

require_once( "$IP/extensions/googleAnalytics/googleAnalytics.php" );

include( "$IP/extensions/AuthPluginLCA.php" );
$wgAuth = new AuthPluginLCA;

$wgGroupPermissions['*']['edit'] = false; // MediaWiki 1.5+ Settings
$wgGroupPermissions['*']['createaccount'] = false; // MediaWiki 1.5+ Settings

###enabled for debug only

$wgShowSQLErrors = true;
$wgDebugDumpSql  = true;

$wgDebugLogFile = "/srv/http/wiki-debug.log";
Comment 1 matanya 2012-08-01 15:16:29 UTC
Sounds like something is wrong with you external plugin and not in mediawiki. One more point is, did you remove the old wiki and installed a fresh one or did you upgrade?
Comment 2 Steve Walsh 2012-08-02 00:05:57 UTC
Hi Matanya

thanks for the reply. Due to privacy issues, every year gets a new VM, so this was a clean install from the 1.19.1 tar.gz.

The query I highlighted will always fail (I believe), as it's trying to compare text to an integer to see if it matches any existing blocks in the database, which is just going to go to custard.

Should the ipb_range_start column be an int and not text?
Comment 3 Steve Walsh 2012-08-05 13:32:53 UTC
OK, thinking about that for a a few days, I can see that changing those columns to int won't work for ipv6, so they need to remain text. 

This still looks like a problem with the query itself, not our plugin, it's just our plugin triggering the issue.
Comment 4 Steve Walsh 2012-09-12 14:00:03 UTC
This also occurs with a clean 1.18.5 install and just my auth plugin

Query: SELECT * FROM "ipblocks" WHERE ipb_address IN ('123123123123','123123123123') OR ((ipb_range_start LIKE '%' ) AND (ipb_range_start <= 0) AND (ipb_range_end >= 0))
Function: Block::newLoad
Error: 1 ERROR: operator does not exist: text <= integer

I'd be really interested in knowing if this is an actual bug with MW, or something else.
Comment 5 Sumana Harihareswara 2013-02-11 15:26:31 UTC
Krenair, could you take a moment to look at this?
Comment 6 Alex Monk 2013-02-11 20:35:12 UTC
That query works for me in MySQL if I get rid of the apostrophes around the table name. This sounds like something has been tested to work with MySQL but not PostgreSQL. I don't know anything about that database system though, so I can't help.

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