Extension talk:AuthDrupal

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)

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:

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)

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:

To:

Then add this function after Auth_drupal_autologin_hook:

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

http://www.mediawiki.org/wiki/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

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.