Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
<?php
|
2010-08-08 11:55:47 +00:00
|
|
|
/**
|
|
|
|
|
* External authentication with a vBulletin database.
|
|
|
|
|
*
|
|
|
|
|
* Copyright © 2009 Aryeh Gregor
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
|
*
|
|
|
|
|
* @file
|
|
|
|
|
*/
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This class supports the proprietary vBulletin forum system
|
|
|
|
|
* <http://www.vbulletin.com>, versions 3.5 and up. It calls no functions or
|
|
|
|
|
* code, only reads from the database. Example lines to put in
|
|
|
|
|
* LocalSettings.php:
|
|
|
|
|
*
|
2009-12-13 20:45:10 +00:00
|
|
|
* $wgExternalAuthType = 'ExternalUser_vB';
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
* $wgExternalAuthConf = array(
|
|
|
|
|
* 'server' => 'localhost',
|
|
|
|
|
* 'username' => 'forum',
|
|
|
|
|
* 'password' => 'udE,jSqDJ<""p=fI.K9',
|
2011-06-20 07:40:07 +00:00
|
|
|
* 'dbname' => 'forum',
|
2011-06-20 07:00:50 +00:00
|
|
|
* 'tablePrefix' => '',
|
2009-12-14 00:53:13 +00:00
|
|
|
* 'cookieprefix' => 'bb'
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
* );
|
2010-01-10 21:39:47 +00:00
|
|
|
*
|
|
|
|
|
* @ingroup ExternalUser
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
*/
|
|
|
|
|
class ExternalUser_vB extends ExternalUser {
|
2010-07-25 17:47:41 +00:00
|
|
|
private $mRow;
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
|
|
|
|
|
protected function initFromName( $name ) {
|
|
|
|
|
return $this->initFromCond( array( 'username' => $name ) );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
protected function initFromId( $id ) {
|
|
|
|
|
return $this->initFromCond( array( 'userid' => $id ) );
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-14 00:53:13 +00:00
|
|
|
protected function initFromCookie() {
|
|
|
|
|
# Try using the session table. It will only have a row if the user has
|
|
|
|
|
# an active session, so it might not always work, but it's a lot easier
|
|
|
|
|
# than trying to convince PHP to give us vB's $_SESSION.
|
2010-08-06 15:00:43 +00:00
|
|
|
global $wgExternalAuthConf, $wgRequest;
|
2009-12-14 00:53:13 +00:00
|
|
|
if ( !isset( $wgExternalAuthConf['cookieprefix'] ) ) {
|
|
|
|
|
$prefix = 'bb';
|
|
|
|
|
} else {
|
|
|
|
|
$prefix = $wgExternalAuthConf['cookieprefix'];
|
|
|
|
|
}
|
2010-08-10 13:30:46 +00:00
|
|
|
if ( $wgRequest->getCookie( 'sessionhash', $prefix ) === null ) {
|
2009-12-14 00:53:13 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
|
2009-12-14 00:53:13 +00:00
|
|
|
$db = $this->getDb();
|
|
|
|
|
|
|
|
|
|
$row = $db->selectRow(
|
|
|
|
|
array( 'session', 'user' ),
|
|
|
|
|
$this->getFields(),
|
|
|
|
|
array(
|
|
|
|
|
'session.userid = user.userid',
|
2010-08-06 15:00:43 +00:00
|
|
|
'sessionhash' => $wgRequest->getCookie( 'sessionhash', $prefix ),
|
2009-12-14 00:53:13 +00:00
|
|
|
),
|
|
|
|
|
__METHOD__
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
);
|
2009-12-14 00:53:13 +00:00
|
|
|
if ( !$row ) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
$this->mRow = $row;
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
|
2009-12-14 00:53:13 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private function initFromCond( $cond ) {
|
|
|
|
|
$db = $this->getDb();
|
|
|
|
|
|
|
|
|
|
$row = $db->selectRow(
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
'user',
|
2009-12-14 00:53:13 +00:00
|
|
|
$this->getFields(),
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
$cond,
|
|
|
|
|
__METHOD__
|
|
|
|
|
);
|
|
|
|
|
if ( !$row ) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
$this->mRow = $row;
|
|
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2009-12-14 00:53:13 +00:00
|
|
|
private function getDb() {
|
|
|
|
|
global $wgExternalAuthConf;
|
2011-10-14 21:18:38 +00:00
|
|
|
return DatabaseBase::factory( 'mysql',
|
|
|
|
|
array(
|
|
|
|
|
'host' => $wgExternalAuthConf['server'],
|
|
|
|
|
'user' => $wgExternalAuthConf['username'],
|
|
|
|
|
'password' => $wgExternalAuthConf['password'],
|
|
|
|
|
'dbname' => $wgExternalAuthConf['dbname'],
|
|
|
|
|
'tablePrefix' => $wgExternalAuthConf['tablePrefix'],
|
|
|
|
|
)
|
2009-12-14 00:53:13 +00:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private function getFields() {
|
|
|
|
|
return array( 'user.userid', 'username', 'password', 'salt', 'email',
|
|
|
|
|
'usergroupid', 'membergroupids' );
|
|
|
|
|
}
|
|
|
|
|
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
public function getId() { return $this->mRow->userid; }
|
|
|
|
|
public function getName() { return $this->mRow->username; }
|
|
|
|
|
|
|
|
|
|
public function authenticate( $password ) {
|
2009-12-13 20:24:17 +00:00
|
|
|
# vBulletin seemingly strips whitespace from passwords
|
|
|
|
|
$password = trim( $password );
|
Add experimental new auth framework, ExternalAuth
This should not affect any existing behavior. (Except that it reorders
some error conditions in attemptAutoCreate(), but probably no one cares
about that.) It adds a new database table, but it will be unused unless
you enable external authentication.
An outline of the rationale for this system, and the design planning, is
at <http://www.mediawiki.org/wiki/ExternalAuth>. Essentially,
AuthPlugin puts too much of a burden on plugin authors, requiring them
to write a lot of policy logic instead of just handling the actual
interface to the external user database. This system uses a standard
framework to decide policy questions, and auth plugins only need to
provide some low-level, clearly-specified data.
There are lots of features still missing, marked in the code, but basic
functionality is present. The commit includes initial support for one
type of external authentication, the forum software vBulletin (which I
happen to know well, and want to integrate with my MediaWiki).
I'm encouraging the inclusion of ExternalAuth plugins in core because in
this framework, the amount of code required to add an additional backend
is quite small -- well under 100 lines in this case. I'd hope to see a
lot more of these, and it seems unreasonable to make an armada of tiny
extensions instead of letting them live happily in their own directory
out of everyone's way.
2009-07-19 22:02:00 +00:00
|
|
|
return $this->mRow->password == md5( md5( $password )
|
|
|
|
|
. $this->mRow->salt );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function getPref( $pref ) {
|
|
|
|
|
if ( $pref == 'emailaddress' && $this->mRow->email ) {
|
|
|
|
|
# TODO: only return if validated?
|
|
|
|
|
return $this->mRow->email;
|
|
|
|
|
}
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function getGroups() {
|
|
|
|
|
$groups = array( $this->mRow->usergroupid );
|
|
|
|
|
$groups = array_merge( $groups, explode( ',', $this->mRow->membergroupids ) );
|
|
|
|
|
$groups = array_unique( $groups );
|
|
|
|
|
return $groups;
|
|
|
|
|
}
|
|
|
|
|
}
|