Extension talk:AuthDrupal

Missing AuthPlugin.php

I downloaded the extension using the following path http://thinkling.com/pub/src/AuthDrupal/AuthDrupal-0.7.2.tgz . It is missing the AuthPlugin.php hence the throws errors. Please update the correct code in that location.

Deeper integration using DB triggers

from Paul Coghlan

I have setup MySQL triggers within my Drupal database to synchronize other features. For example, we allow a multi-lingual interface in Drupal. A trigger to change the language=en string in the user_options BLOB at Mediawiki to language=it means people switching to Italian in Druapl see an Italian Mediawiki too! I also prevent people from editing wiki pages until they are approved within Drupal, again a trigger carries the permission across. - Paul Coghlan. Mar 31 2007

uid sync issues between MW and Drupal

I have spent some time adding levels of integration between Drupal and Mediaiwki and have come across a potential issue.

We are running queries against the database that extracts and presents information for a specific user to their front page. For example, pages they are watching (Mediawiki), number of private messages (Drupal) etc.

In doing so we have discovered that the uid in Drupal doesn’t always match the user_id in Mediawiki. The problem appears to be as follows:

When you create a new account in Drupal there is not yet a matching record in Mediawiki. Assuming you are using email verification then the user returns to Drupal using the emailed link and logs in. The user still does not exist within Mediawiki. They might use Drupal for the next several days without needing to view a Mediawiki page. If this is the case then they do not ‘exist’ within the Mediawiki user table yet. Only once they first visit a Mediawiki page do they get inserted into the Mediawiki table. This can cause an issue in matching Drupal-Mediawiki uids because if two members join; member 1 and 2, and member 2 goes to a Mediawiki pages BEFORE member 1 then their user_id’s will be reversed in Mediawiki. Make sense?

My plan is to create a new trigger that upon the creation of the user within Drupal immediately creates the user within Mediawiki through SQL. This would ensure the uid’s always match and that the user immediately exists in both platforms. My only fear is whether AuthDrupal would try to create them a second time once they first visit a Mediawiki page or whether it only creates them when it sees they don’t already exist?

Could you let me know what it is that makes AuthDrupal try to create a new user in Mediawiki? I am pretty confident that if it sees the user as already existing (through my trigger) it will not try to recreate them.

I have managed to integrate other triggers. For example, changing the language at Drupal changes Mediawiki too. Also, I can handle group management through triggers too; when I add a member as a moderator at Drupal they are also added as one within Mediawiki. These triggers are a life saver.

Paul Coghlan - 10:39, 29 May 2007 (ET)

Did Paul's code ever get posted anywhere? It would be useful to me, but he doesn't seem to have a user page. Thx in advance. --Md96 22:39, 19 October 2011 (UTC)

SUCCESS!

I now have user ID synchronization working seamlessly between Drupal and Mediawiki. This also provides creation of the Mediawiki member at the same instant as the creation of the Drupal member.

The modifications provide the following features:

- New Drupal member immediately propagated across to Mediawiki - The Mediawiki userid is fed from the Drupal uid (auto-increment is turned off) - A deleted Drupal member is also deleted from Mediawiki

The benefits of this, at least for me, are huge. One simple example, I am now able to present an accurate "number of posts" that takes into account both the user's Drupal and Mediawiki forum/blog/wiki posts as well as integrating a hundred other stats.

I will send the code to Maarten for possible inclusion on the wiki page. If it is not appropriate to include it there I will post it here.

Paul - June 1st 2007 17:30

Logging users out of MW on Drupal cookie expiration

I had a problem in that we expire our cookies once the user closes their browser. Mediawiki was keeping users logged in even thouggh Druypal wasnt and it was confusing. Thanks to Maarten and some testing I now have them working in full sync. If you want this configuration just make the change below to the Mediawiki.module file.

To get AuthDrupal to use session based cookies make the following change to Mediawiki.module:

Where it currently says

$exp = time() + 2592000; //one month in seconds

change it to

$exp = 0; // expire at end of session

To get Mediawiki to act likewise enter this into LocalSettings.php

$wgCookieExpiration=0;

Paul Coghlan - August 23rd 2007

Returning after login

When user clicks over to the Drupal page to log in, there's no mechanism to bring them back to the wiki page they came from. If anyone has tips on how to implement this, please leave a note on the talk page.

Use Drupal's destination URL parameter to redirect to a path owned by your Drupal module, which in turn redirects to the wiki. MediaWiki's returnto parameter can be stored in a cookie for the time being.

Alternately, you could login and set the cookie via AJAX, then just reload the page. --Tgr 19:14, 4 February 2009 (UTC)

As Tgr said, here just a code snippet:

<div id="register-block">
    <form action="/user/login/?destination=wiki" method="post" id="user-login">
        <input type="text" maxlength="60" name="name" id="edit-name" size="22" value="" tabindex="1" class="form-text required" />
        <input type="password" name="pass" id="edit-pass" size="20" tabindex="2" class="form-text required" />
        <input type="hidden" name="form_id" id="edit-user-login" value="user_login" />
        <input type="submit" name="op" class="form-submit" tabindex="3" value="Login" alt="Login" />
    </form>
</div>

Kindest regards --Fleshgrinder 21:59, 26 March 2009 (UTC)

I'll look at this for a future release--don't have the bandwidth right now, sorry! Thinkling 01:08, 11 March 2010 (UTC)

Did this get integrated into the December 2010 update? --Md96 22:41, 19 October 2011 (UTC)

I found an alternative way:

In htaccess, Apache vhost, ...

RewriteRule ^wiki/(.*)$ http://<your wiki path>/$1 [L]
</syntaxlighlight>
then in LocalSettings.php:
<syntaxlighlight lang="php">
$wgAuthDrupal_LoginURL = 'http://<your drupal path>/user?destination=/wiki' . $_SERVER['REQUEST_URI'];
$wgAuthDrupal_LogoutURL = 'http://<your drupal path>/user/logout?destination=/wiki' . $_SERVER['REQUEST_URI'];

Drzraf2 20:22, 2 November 2011 (UTC)

Here is my solution for drupal-7.12 and mediawiki-1.17 in LocalSettings.php:

$wikiURL = '<your wiki url>'; // http://mydrupal/wiki
$wikiURLBase = base64_encode($wikiURL); 
$wgAuthDrupal_LoginURL = 'http://<your drupal path>/user?redirect='.$wikiURLBase;
$wgAuthDrupal_LogoutURL = 'http://<your drupal path>/user/logout?redirect='.$wikiURLBase;

Add function for hook_drupal_goto_alter in mediawikiauth.module file

function mediawikiauth_drupal_goto_alter(&$path, &$options, &$http_response_code) { 
  if ( isset($_GET['redirect']) && !empty($_GET['redirect']) ) {
	$wikiURL = base64_decode($_GET['redirect']); 
     $path = $wikiURL;
  }
}

I also added this solution to http://drupal.org/node/1783380 Kindest regards --akki123

update of this for MediaWiki 1.14 and Drupal 6

I have published a new version of this extension that supports MediaWiki 1.14 and that seperates the MediaWiki extension from the Drupal module to allow a port to Drupal 6 while keeping Drupal 5 support.

The new code is here: https://svn.koumbit.net/svn/koumbit/trunk/patches/AuthDrupal/

I can provide a complete patch if necessary.

The Drupal modules are now living here: http://drupal.org/project/mediawikiauth

I hope this is useful to people here. :)

Confirmed to work with Drupal 6.10/MediaWiki 1.13.5 on FreeBSD 7.1/php 5.29/Apache 2.2.11

Confirmed to work with Drupal 6.13/MediaWiki 1.15.1 on Centos 5.3/PHP 5.2.6/Apache 2.2.3

Works for me with drupal 5.6/MediaWiki 1.14; Spoke too soon: it only works for root, anyone else gets an error on the second page they click, and then it gives internal error for every link, including the main page. Weird.

NOTE from AuthDrupal maintainer: I've incorporated User:TheAnarat's fixes for MW 1.13+ into a new release that's working for me on D6.x (6.15, but should all be the same) and MW1.15.1.

Can't seem to get this to work

Running with Drupal 6.13/MediaWiki 1.15.1 on Ubuntu 9.04/

I have followed the instructions carefully and have both sides installed. Have the wiki database details set in mediawikiauth.module and drupal database details set in LocalSettings.php. The drupal users are not being populated into the mediawiki database. So the login doesn't work. Nothing in any of the error logs. Any ideas?

Thanks! --mitchelln 16:45, 02 October 2009 (UTC)

I experienced similar symptoms and noticed the cookies that were supposed to be set by Drupal were not being created in my browsers. I had been using a local IP address as the cookie domain (e.g. 192.168.0.100). Setting wgCookieDomain to an empty string in mediawikiauth.module resolved the issue for me. Drupal 6.10/MediaWiki 1.15.1 on Ubuntu 9.04

--Chou 02:11, 04 October 2009 (UTC)

Thanks for the suggestion, but it didn't work :( The two apps just don't seem to be linked at all. Mediawiki doesn't seem aware of the drupal users. Finding it very frustrating. --mitchelln 15:02, 06 October 2009 (UTC)

Drupal 6 and MW 1.15 user groups issue

I'm having a problem with Drupal 6.14 and MW 1.15 user groups. The groups are not populated from Drupal roles. Anyone had success making it work?

This should be fixed in the 0.7.1 release. Pls note the Drupal module name changed so when installing you'll need to dump the old one, create a new module directory, and enable the new one.

D6/MW1.13+ alternate edit

This is an alternate patch for MW1.13+ based on 0.6.1, by Chris Johanson. Saving here to review later for post 0.7 work.

In Authdrupal.php:

Change this line:

	$wgHooks['AutoAuthenticate'][] = 'Auth_drupal_autologin_hook'; /* Hook for magical authN */

To:

	// Twin Rose 5/16/2009
	// AutoAuthenticate was deprecated in MediaWiki 1.3 use "UserLoadFromSession"
	//$wgHooks['AutoAuthenticate'][] = 'Auth_drupal_autologin_hook'; /* Hook for magical authN */
	$wgHooks['UserLoadFromSession'][] = 'Auth_drupal_UserLoadFromSessionHook';

Then add this function after Auth_drupal_autologin_hook:

function Auth_drupal_UserLoadFromSessionHook($user, &$result) 
{
	global $wgUser;
	global $wgAuth;
	global $wgContLang;

	//! dbg wfDebug("##" . __FUNCTION__ . "\n"); //!dbg XXX remove

	// Give us a user, see if we're around
	// Twin Rose: 5/16/2009
	// We can't call static functiosn because we're calling it FROM a user object.
	// $tmpuser = User::newFromSession();
	// MJ: changed from $tmpuser->loadFromSession();
	//$tmpuser->mFrom = 'session';
	// Now lets check for drupal cookie
	$name = getCurrentDrupalUsername();

	if ( empty( $name ) ) {
		return false;
	}

	$user->mDataLoaded = false;
	$user->mFrom = 'name';
	$user->mName = $name;
	$rc = $user->load();

	// If there's a prior session, check that it matches the current Drupal user
	if ($rc && $user->isLoggedIn()) 
	{
		if ( $wgAuth->authenticate( $user->getName(), '' ) ) {
			//!dbg wfDebug("AuthDrupal: User " . $tmpuser->getName() . " already logged in\n");

			// update email, real name, etc.
			$wgAuth->updateUser( $user );

			return true;

		} else {
			// log out the existing user and continue below to start over
			$user->logout();

			// no return here--fall through to code below
		}
	}

	// is it a new user?
	if ( 0 == $user->getID() ) {
		// we have a new user to add...
		$drupal_user = $wgAuth->getDrupalUser( $name );

		if ( empty( $drupal_user ) ) {
			wfDebug( __FUNCTION__ . " AuthDrupal ERROR: " . $name . " not found in Drupal DB \n" );
			return false;
		}

		//!dbg wfDebug( "AuthDrupal: logging in NEW user " . $name . "\n" );

		// this mimicks what LoginForm::initUser() does (code identical to
		// regular login moved down to common code)
		$user->setName( $wgContLang->ucfirst( $drupal_user->name ) );
		$user->addToDatabase();

		// Update user count in site stats (stolen from SpecialUserlogin)
		$ssUpdate = new SiteStatsUpdate( 0, 0, 0, 0, 1 );
		$ssUpdate->doUpdate();

		// LoginForm::initUser() calls $wgAuth->initUser, but I don't see the point
		// $wgAuth->initUser( $u );
	} else {
		//!dbg wfDebug( "AuthDrupal: logging in existing user " . $name . "\n" );

	}

	// update email, real name, etc.
	$wgAuth->updateUser( $user );

	// Go ahead and log 'em in
	$user->setToken();
	$user->saveSettings();
	$user->setupSession();
	$user->setCookies();

	$message = 'MediWiki session (cookie) opened for <em>' . $name . '</em>.';
	$wgAuth->drupal_uid = $user->getID();
	$wgAuth->logit( $message );

	$return_user = $user;
	return true;
}

Logout issues

Currently running Drupal 6.16 with the new version of AuthDrupal. I have a problem in that when I log out of drupal, the cookie 'wikidb_session' is not cleared so I can still access the wiki with the logged in user. The DXArgs/2 cookies go and the loggedout cookie is set? This was working with the patched version of 0.6? What am I doing wrong! Aaron Horn...

Hmm, this is working correctly on my end. Are the _UserName and _UserId cookies getting unset correctly, but not the _session? Be sure to check the settings on the Drupal side at the top of mediawikiauth.module. The wgDBname and wgDBprefix are used to figure out the names of the cookies that need to be unset, so those settings have to be right for things to work. Thinkling 21:27, 15 March 2010 (UTC)

Does it allow only simple usernames or email address used as username also?

Does the extension allow only simple text based usernames forauth or can work with email address used as username also?

MediaWiki does not seem to allow email address based usernames and thus the websites cannot have email address as username. Is it correct?

I haven't done extensive testing, but I have had users choose an email address as their Drupal username and successfully edit the wiki, so it seems to work OK. The downside of course is that you expose your email address to people harvesting addresses off the web for spammers, so I wouldn't recommend it. Thinkling 17:52, 10 November 2010 (UTC)

Drupal usernames with underscores

There seems to be a major issue with users in Drupal that have underscores in their usernames, not being authenticated on MediaWiki with this module. I think this has something to do with MediaWiki converting the underscores to spaces internally. Does anyone know how to fix this? (Originally posted by anonymous user at 195.26.247.141.)

Alternate way to block Special:Userlogin

Edit from 24.54.48.118 by "HUB":

I tried hard to block Special:Userlogin with htaccess and as my wiki is in french, i really did not find how to get it working...

So I found this link within my searches that show how to totally disable some specials pages with a couple of lines into LocalSettings.php

Manual:Special pages#Disabling Special:UserLogin and Special:UserLogout pages

It seems to work fine, i also tried to add the special page ChangePassword, but instead of saying "This page does not exist", it say that passwords cannot be changed. And the page is still in the Special pages list...

I'll add that link to the readme for the next release. You don't need to do anything to stop users from changing their password--AuthDrupal already does that through the AuthPlugin API. (If you find that's not working, please report it here.)

How about 1.0?

It would be nice if we could head for a 1.0 release... The 0.x naming convention is making our work harder over at Drupal.org, because they do not allow 0.x.y releases, which means that if we want to make a bugfix release, we will break the matching versions convention (0.8 != 0.7). If we go for a 1.x release convention, then we can have 1.0 here and 1.1 at drupal.org and it's still obvious they are compatible (1.x would be a stable API)...

For example, this issue details a new incompatibility between the releases... If we would settle on one, then those things would not happen until one of us decides to break the API, which would involve a 2.x release.

How does that sound? -- TheAnarcat 2011-02-26

-- ATM MediaWiki 1.25 / 0.7.2 + patch (see bottom) do NOT work together any more. I'd not call that 1.0... --Ddroetker (talk) 18:28, 19 June 2015 (UTC)

A patch for AuthDrupal to use either "classic" profile and cck fields.

if you dont have real names just in profile table, you cannot be able to insert real names from drupal into mediawiki db. In my case I have real names in special cck contents aimed to archive several data of users who are members of a special group. This is required by other custom modules that manage deliberative proceedings and other stuff. As usual many workarounds was possible. But I didnt wish to create new specific profiles nor force the users to reinsert data already living in drupaldb.

Shortly, I needed to keep realnames from these cck contents.

So i wrote this patch.

My configuration is: Drupal 6.20 MediaWiki 1.16.1

regarDDs

User::SetupSession() has been removed

Based on an email received -- putting here as note-to-self:

User::SetupSession() is removed. Code should use wfSetupSession() instead.

2011 update

Experiencing the need to:

• have only one directory to fetch/install for both applications
• having the code under a DVCS
• update to the latest MediaWiki hooks/API
• cleanup the code, reduce the use of GLOBALS and the number of options which may be easily fixed rather than user-defined

I have given a big update to the code at http://gitorious.org/drzraf/drupal-mediawiki (until both MW and Drupal upstreams may have a common repository the handle a clean and dynamic AuthDrupal-mediawikiauth codebase.) After a 0.7.3 tag, the "custom" branch currently does the switch to php-mcrypt. Drzraf2 00:32, 20 November 2011 (UTC)

How about postgresql?

Variables in AddToLocalSettings.php ($wgAuthDrupal_MySQL_Host and friends) seem to suggest that AuthDrupal works only with MySQL. However, I did not see anything in documentation which says this module is MySQL specific.

Role migration from Drupal to MW?

According to my settings all roles should be propagated yet the table mw_user_groups is empty. Do Drupal group names need to match MW ones? This part was vaguely documented.

Using in MediaWiki 1.22

The following changes from v0.7.2 are necessary:

Line 221: Replace

$user->setupSession();

with

wfSetupSession();

Line 440: Replace

			$this->my_dbr = & Database :: newFromParams(
					$GLOBALS['wgAuthDrupal_MySQL_Host'],
					$GLOBALS['wgAuthDrupal_MySQL_Username'],
					$GLOBALS['wgAuthDrupal_MySQL_Password'],
					$GLOBALS['wgAuthDrupal_MySQL_Database'],
					'auth_drupal_db_error_callback' );

with

			$this->my_dbr = new DatabaseMysql();
			$this->my_dbr->open(
					$GLOBALS['wgAuthDrupal_MySQL_Host'],
					$GLOBALS['wgAuthDrupal_MySQL_Username'],
					$GLOBALS['wgAuthDrupal_MySQL_Password'],
					$GLOBALS['wgAuthDrupal_MySQL_Database']);

You might have to use a different Database class for PostreSQL.

Comment: new DatabaseMysql(); throws an error in Mediawiki 1.25: "Catchable fatal error: Argument 1 passed to DatabaseBase::__construct() must be an array, none given" - seems that giving no argument to the constructor is deprecated. --Ddroetker (talk) 12:47, 18 June 2015 (UTC)

Error in MW 1.23

When using it in MW 1.23 it works, if you are logged in in Drupal. But if you are not, the following error appears: Fatal error: Call to undefined function authdrupal_StaticUserLogout() in .../extensions/AuthDrupal/AuthDrupal.php on line 132

Error after upgrade from PHP 5.3 to 5.5

After an upgrade from PHP 5.3 to 5.5, I get the following error:

Strict Standards: Declaration of AuthDrupal::initUser() should be compatible with AuthPlugin::initUser(&$user, $autocreate = false) in ../extensions/AuthDrupal/AuthDrupal.php on line 374

Solution

in AuthDrupal.php

-458 $dbr = & $this->getDB();
+458 $dbr = $this->getDB();

-769 function initUser( & $user) {
+769 function initUser( & $user, $autocreate = false ) {

Upgrade to MW 1.28

We had the following problems coming from 1.26-2

• Function wfMsg in AuthDrupal.php no longer exists. Replace with wfMessage
• ShowIPInHeader var does not exist any more (AuthDrupal.php). Removed its occurence in a test.
• The database class must be instantiated with the factory method. $this->my_dbr = DatabaseMysql::factory( "mysql", $params );
• In our AuthDrupal.php we had a $user->SetToken() call. After commenting out that line it solved a Session Lost! message originating from EditPage.php.

Recreated extension with SessionProvider for MW 1.27+

I tried to update this extension for MW 1.27+ with new SessionProvider framework. Related issue on mediawikiauth module page on drupal.org - Drupal to mediawiki site SSO bridge is not generating Cookie

GitHub Repo

I have created a public repo on GitHub for the AuthDrupal extension. Collaborators are welcome. Darren Oh (talk) 15:09, 23 June 2023 (UTC)