Extension talk:AuthDrupal

MW 1.6.x with Drupal 5.1: not working
For me, AuthDrupal doesn't work with Drupal 5.1. Basically, the installation seems to go smoothly, but when switching from Drupal to MediaWiki (v1.6.10), I'm user "Anonymous". Thus I can't edit "MediaWiki:Whitelistedittext", so the "Login" link still exists. With the "Login" link, I can log in to MediaWiki with my old MediaWiki credentials, but when accessing another page, I'm immediately "Anonymous" again. Differences in my setup might be: I'm using a localized version if MediaWiki (not English, but German); and access to the wiki pages isn't public but limited to logged in users. However, thank you for the effort; please feel free to contact me, if I can help with anything (testing new code etc.). -asb 19:20, 29 March 2007 (UTC)


 * The code is tested only with MW 1.9.x. I have no idea whether MW 1.6.x has the same hooks that I'm relying on to make the extension work, sorry. If you're up for a bit of debugging, you might want to see if the hooks are getting called at all. (do a wfDebug and look at the debug output log.) Thinkling 03:10, 1 April 2007 (UTC)

No luck for me either
This did not work for me. I'm using Drupal 5.0rc1 and Mediawiki 1.93. Basically, the login link on Mediawiki points to Drupal but there is no impact of logging into Drupal on Mediawiki. I'd appreciate any help/advice. - Samir March 31 2007


 * Hi, can you confirm that you edited the cookie domains? I did a ton of testing in Drupal 5.1 and have nw got it down to a fine art with a 15 minutes installation from scratch. I have installed it on 4 servers now with Drupal 5.1 and MW 1.9.3 and each time it worked straight out of the gate. Shout if I can help. - Paul Coghlan. Mar 31 2007


 * I did remove the cookies. I think I should upgrade from Drupal 5.0rc1 to Drupal 5.1 asap before bothering you some more. I'll do that and report back. Thanks! - Samir April 2, 2007


 * My guess is that the version of Drupal you use makes no difference, but that something else is going on. I think you misunderstood Paul's question. He was asking whether you have changed the settings for the way AuthDrupal cookies are created, both in LocalSettings.php and in Mediawiki.module. Thinkling 20:06, 2 April 2007 (UTC)
 * Make sure that the php session path folder has the apache write privileges. It's usally under /var/lib/php/session - April 5 2007

OTHER INTEGRATION
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

Multi-Lingual wikis now working
I am now running three languages at my site and AuthDrupal is logging the Drupal user in for all three wikis (English, Spanish and Italian). Each appears to work absolutely fine with no ill effects. Shout if you need any pointers on this feature - Paul Coghlan 3rd June 207 (pcoghlan at usa.net )

Using session based cookies in Drupal?
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

Drupal 5.2 + MW 1.10.x
Trying to set up AuthDrupal with Drupal 5.2 and MediaWiki 1.10.x results in my setup in the following behaviour:


 * Logging in into Drupal works as usual; switching to MediaWiki leaves me not logged in into MediaWiki. I can't edit pages in MediaWiki.
 * Clicking on "Log in" in MediaWiki sends me to http://www.exaple.com/drupal/user/login (the defined login Url); since I'm already logged in into Drupal, Drupal gives me an "Access denied" for this page.
 * After logging off from Drupal, I can repeat this procedure.


 * Doing it the other way around results in similar behaviour: Not logging in first in Drupal, but loading first the MediaWiki site and then clicking on "Log in" in MediaWiki sends me to the Drupal Login page, which is now accessible; I can login into Drupal, which works fine, and then switch back to MediaWiki, wehere I am still not logged in.

Any ideas or suggestions? --asb 14:53, 27 August 2007 (UTC)


 * I would like to hear more about possible integration with Drupal 5.2 and MediaWiki 1.10.x. Is there any news on an update for this?  -Ishmayl


 * I successfully setup 5.2 and Mediawiki 1.10.1. I have a few notes for the maintainers.
 * mediawiki_perm in mediawiki.module serves no purpose and can be deleted.
 * we can be smarter about the login link. specifically, append a destination= and drupal will redirect to after its login processing is complete. that works for any drupal form. Unless Mediawiki has a better way, I suggest a querystring like: $GLOBALS['wgAuthDrupal_LoginURL'] . '?destination='. urlencode(substr($_SERVER['REQUEST_URI'],1)).
 * Drupal 5.2 has $cookie_domain specified in settings.php so it does not need to be respecified in mediawiki.module. Just tell folks they must edit their settings.php in drupal for $cookie_domain. -MosheWeitzman

Drupal 5.3 MW 1.11
I was a little aggressive and added a block of text to the Wiki article showing changes I made to AuthDrupal to make it work with Drupal 5.3 and MW1.11.

There are still issues with it that I am going to have to look at (receive stack trace errors when trying to visit the MW anonymously).

Feel free to contact me if anyone has any questions. I was in a hurry adding the content to the front page and it can be made "prettier"

Mconway 19:47, 8 November 2007 (UTC)


 * I visited your site and it seems to me you have the same "Hook Auth_drupal_loginlink_hook failed to return a value" problem with integration of MW and Drupal. Me personally have Drupal 5.7 and MW 1.11 So do you know any possible measures to fix this problem? --Alex-and-r 12:25, 18 February 2008 (UTC)

Porting to Drupal 6
Is there work currently planned to port this module so that it will work in Drupal 6.0 (or has anyone tested it there)? I love how this add-on works, but I don't want to get locked into an old version of Drupal over it.


 * The part of AuthDrupal that lives on the Drupal side is VERY simple, so it should be an easy port, and I'm sure it'll happen eventually. I'm not planning to look at it myself until some time after D6 is released and major modules are stable.


 * If someone wants to dive in and try it, you'll need to look at two things: (1) check that the hook_user call interface hasn't changed its parameters or what's passed specifically for login/logout, and (2) look at AuthDrupal.php for methods called getDrupal... which reach into the Drupal database--and verify that the schema hasn't changed to break them. 216.162.200.34 01:28, 23 January 2008 (UTC)

upgrade to 5.7 gives error message
I have upgraded Drupal to 5.7 and am seeing the following error message.

Any ideas on what might cause this?

Thanks, pcoghlan - Feb 20 2008

Fatal error: Call to a member function getID on a non-object in /home/scribas/public_html/archives/extensions/AuthDrupal/AuthDrupal.php on line 183

I get this page of error messages when I installed it and followed the instructions earlier.

MediaWiki internal error.

Original exception: exception 'MWException' with message 'Detected bug in an extension! Hook Auth_drupal_autologin_hook failed to return a value; should return true to continue hook processing or false to abort.' in /home/fatalfit/public_html/athlepedia/includes/Hooks.php:133 Stack trace:
 * 1) 0 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(131): wfRunHooks
 * 2) 1 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(57): StubUser->_newObject('AutoAuthenticat...', Array)
 * 3) 2 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(31): StubObject->_unstub
 * 4) 3 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(122): StubObject->_call('isAllowed', 5)
 * 5) 4 [internal function]: StubUser->__call('isAllowed', Array)
 * 6) 5 /home/fatalfit/public_html/athlepedia/includes/Title.php(1269): StubUser->isAllowed('isAllowed', Array)
 * 7) 6 /home/fatalfit/public_html/athlepedia/includes/Wiki.php(133): Title->userCanRead('read')
 * 8) 7 /home/fatalfit/public_html/athlepedia/includes/Wiki.php(43): MediaWiki->preliminaryChecks
 * 9) 8 /home/fatalfit/public_html/athlepedia/index.php(89): MediaWiki->initialize(Object(Title), Object(StubObject), Object(WebRequest))
 * 10) 9 {main}

Exception caught inside exception handler: exception 'MWException' with message 'Detected bug in an extension! Hook Auth_drupal_autologin_hook failed to return a value; should return true to continue hook processing or false to abort.' in /home/fatalfit/public_html/athlepedia/includes/Hooks.php:133 Stack trace:
 * 1) 0 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(131): wfRunHooks
 * 2) 1 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(57): StubUser->_newObject('AutoAuthenticat...', Array)
 * 3) 2 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(31): StubObject->_unstub
 * 4) 3 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(122): StubObject->_call('getOption', 5)
 * 5) 4 [internal function]: StubUser->__call('getOption', Array)
 * 6) 5 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(92): StubUser->getOption('getOption', Array)
 * 7) 6 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(57): StubUserLang->_newObject('language')
 * 8) 7 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(31): StubObject->_unstub
 * 9) 8 /home/fatalfit/public_html/athlepedia/includes/StubObject.php(87): StubObject->_call('getCode', 5)
 * 10) 9 [internal function]: StubUserLang->__call('getCode', Array)
 * 11) 10 /home/fatalfit/public_html/athlepedia/includes/MessageCache.php(434): StubUserLang->getCode('getCode', Array)
 * 12) 11 /home/fatalfit/public_html/athlepedia/includes/GlobalFunctions.php(467): MessageCache->get
 * 13) 12 /home/fatalfit/public_html/athlepedia/includes/GlobalFunctions.php(421): wfMsgGetKey('internalerror', true, false)
 * 14) 13 /home/fatalfit/public_html/athlepedia/includes/GlobalFunctions.php(326): wfMsgReal('internalerror', true, false, true)
 * 15) 14 /home/fatalfit/public_html/athlepedia/includes/Exception.php(57): wfMsg('internalerror', Array, true)
 * 16) 15 /home/fatalfit/public_html/athlepedia/includes/Exception.php(125): MWException->getPageTitle('internalerror')
 * 17) 16 /home/fatalfit/public_html/athlepedia/includes/Exception.php(88): MWException->htmlHeader
 * 18) 17 /home/fatalfit/public_html/athlepedia/includes/Exception.php(111): MWException->reportHTML
 * 19) 18 /home/fatalfit/public_html/athlepedia/includes/Exception.php(191): MWException->report
 * 20) 19 /home/fatalfit/public_html/athlepedia/includes/Exception.php(225): wfReportException
 * 21) 20 [internal function]: wfExceptionHandler
 * 22) 21 {main}

The above problem for Drupal 5.7 was solved by returning true for the three functions mentioned here.

Additionally, while using MediaWiki SVN I got: Notice: Use of User::SetupSession is deprecated in includes/GlobalFunctions.php on line 2474. I worked around it by replacing $user->setupSession with wfSetupSession in AuthDrupal.php

Drupal5.x not working
Hello everybody, I'm really up sate about abt mediawiki module(drupal 5.x) .. i have tried near abt 5 times ...but unable to automatic login in wiki.. please help me ...

my mail id dibyendu.bigeat@gmail.com

Hope to hear from you soon :((


 * Hard to help you unless you say more about your setup, specific errors, etc. The current version is known to work with Drupal 5.7 and MW 1.11 User:Thinkling

Any new updates?
Any new updates on this? I would love to use this extension with Drupal. I have mediawiki 1.12, Drupal 5.3, and this extension does not work right now. Any work being done? --Ishmayl 02:32, 6 June 2008 (UTC)

Error after installing module
My error only appears on login, viewing the wiki annonymously is still possible. NOTE that I have seen and implemented the fixes listed above for an error like this one. They just aren't working. You may contact me via email at: Mike@savetheshows.com. Thanks!

(User:Thinkling -- Text removed here to keep page compact: same error messages as "internal mediawiki error" reported above.  )

Interaction with Groups?
I'm trying to integrate Mediawiki 1.12.0 with Drupal 5.7, but being new to Mediawiki I'm not sure whether the problems I'm having are mine, or are with AuthDrupal.

I get no errors (on the Mediawiki side) when I open the wiki page, but neither is my level of access carried forward to the wiki as it's supposed to be. So maybe thinkling can document an undocumented question for lil'ol' newbie me:

What does AuthDrupal do with the Drupal roles? How should they be assigned/handled on the Mediawiki side to allow various levels of access?

You say in the the accompanying commentary in "AddToLocalSettings.php" that the labels "users", "roles" and "users_roles" should be changed to match our database? What does that mean? Those variables are standard to Drupal (so far as I know). The only additional factor being a prefix for cases where more than one instance of Drupal is running -- which you account for.

My thought with the above is that access levels are not being properly read from the Drupal users table. But that would generate an error -- or at least a log entry, wouldn't it?

Thanks.

--Blackhawke 15:33, 14 July 2008 (UTC)


 * The roles/groups code is hacky and has no error checking or error reporting in it. I haven't upgraded to MW 1.12 yet, so I don't know if there were changes from 1.11 to 1.12 that broke that code. Yes, the settings for the table names are basically unnecessary, the defaults should work.


 * What should happen is that for each role that the Drupal user has, the corresponding MW user is added to the MW group of the same name. You can then create some (global) access control (read/write/etc) based on group membership. See Manual:User rights.


 * When you say "neither is my level of access carried forward to the wiki as it's supposed to be", what do you mean? You're not logged in on the MW side? Or you expected access restrictions to be enforced?


 * Thinkling 17:02, 14 July 2008 (UTC)


 * I mean I'm not even a "user" never mind being a top level admin.  With AuthDrupal turned on, the login button disappears and so does the edit button. If I click on the "View Source" button I get the notice that "The action you have requested is limited to users in the group user." That's it. Were my roles on Drupal being properly translated I think I'd at least be an Admin in Mediawiki.


 * But, I haven't done anything with "users rights", either.


 * If I'm understanding you correctly, each Drupal "role" is turned into a Mediawiki "group" and I need to assign a right to each of those groups on the Mediawiki side. The reason I have no access on the wiki is because I haven't assigned any rights to those "roles" AuthDrupal has translated into "groups", nor am I a member of any of the default groups that Mediawiki understands.


 * Am I even close? :)


 * --Blackhawke 00:37, 15 July 2008 (UTC)


 * The "not even a user" part must be the main problem here... I wouldn't expect the rest to work without a valid user object. There are two likely reasons why it's not working: either your settings don't quite match between LocalSettings.php and Mediawiki.module (or is your domain localhost by any chance?), or something changed in MW 1.12 that broke AuthDrupal. Sorry it's giving you a hassle!


 * Aside from that, when login of the user is working, Drupal roles are turned into MW group membership simply based on names. The main Drupal admin user does not automatically turn into a MW admin. If you wanted to do something where only certain users are allowed to edit pages, you could deny editing by default, and allow if for a certain group , and then assign Drupal users to a role of that name (mygroupname).


 * Thinkling 15:59, 15 July 2008 (UTC)


 * Well, all I can say is that if I "turn off" AuthDrupal things seem to work normally. I.E. I can either login as the default admin (created at install time) or I can edit a page without logging in, in which case MediaWiki dutifully notifies me that my IP address will be logged.


 * So if that's the normal behavior for a default MediaWiki installation, then that limits the problem to either my ignorance of your extension or a change in MW 1.12.


 * I'll try assigning "mygroupname" permissions and see if that helps. BTW, does MediaWiki allow spaces in a group name? Two DruPal roles have blank spaces in them.


 * --Blackhawke 17:37, 15 July 2008 (UTC)


 * The roles/groups are not your main problem. Without touching or setting up the roles/groups at all, normal behavior is that AuthDrupal turns a logged-in Drupal user into a normal logged-in Mediawiki user, and as long as registered users have permission to edit on the Mediawiki side (which sounds like your users have, it's certainly the default in MW config), it should all work. (AuthDrupal is auto-creating the MW user object under the covers.)


 * So the problem to solve first is getting MW to recognize you as a logged-in user. Check to see that the two DXtrArgs cookies are getting set, and that your cookie domain names match in the setup. (You sound savvy so I'm guessing you've already double checked that.)


 * I don't have the bandwidth right now to install MW 1.12 and see if that's what's causing the problems, sorry.


 * Thinkling 19:35, 15 July 2008 (UTC)


 * Duh! Actually no, I hadn't thought to check it, but I just did. DXtrArgs shows my Drupal username and the domain name as ".foo.bar" (name changed to protect the guilty. :D)


 * The second cookie shows wgDBprefix+wgDBname followed by my Drupal "role". But, the domain name is "foo.bar" not ".foo.bar". Dunno if it's supposed to drop the leading dot or not.


 * I also have a third cookie labeled with wgDBprefix+wgDBname+UserID 1 (which isn't my Drupal user ID, interestingly enough). It too lacks the leading dot in the domain name.


 * Hope this helps.


 * --75.111.48.207 14:27, 16 July 2008 (UTC)


 * Those wgDBname_wgDBprefix_UserName and _UserID cookies are set by Mediawiki internally. They contain what Mediawiki thinks your username and userID are... the username would be the same as your Drupal username (except maybe changed to be "canonicalized", i.e. with a leading capital letter the way Mediawiki wants everything), but the UserID would most likely be different. The fact that those cookies are set suggests that most of what AuthDrupal does is working, because they are created by the Mediawiki login code, which gets called by AuthDrupal if it has found that you're a valid user.


 * At this point I'm guessing the problem is with MW 1.12.  17:26, 16 July 2008 (UTC)


 * Meaning... I have something configured wrong, or something is changed in MW 1.12 soe AuthDrupalisn't entirely working right or what?


 * --Blackhawke 15:33, 17 July 2008 (UTC)


 * Most likely the latter--probably something in 1.12 broke AuthDrupal.

Well here's an interesting little tidbit that I just observed. (And I don't know why I didn't see this before since it's right in front of me.)

Anyway, the "login/create account" option is still there even though ($wgGroupPermissions['*']['createaccount'] = false;) is uncommented. The other part of this ($wgGroupPermissions['*']['edit'] = false;) in LocalSettings.php still works just fine. But MW 1.12 seems to be ignoring the "createaccount" command.

Also, when I click to login, my DruPal "role" is treated as my username, rather than being a MW "group".

Hope this helps.

--Blackhawke 03:48, 18 July 2008 (UTC)

Drupal 5.3 + MW 1.12.0 does not work
I found that the DRXtrArgs[UserName] is not written to the cookie. The $wgCookieDomain in both LocalSettings.php and Mediawiki.module are set to be the same as the $cookie_domain in the settings.php of Drupal. I use ssl for this server. The 4.0 version works for one of my servers. I have the same Drupal and MW on that server, but without ssl. However, for the server I could not have the AuthDrupal work, even though I try to use the 4.0 version and disable ssl, it is still not working. Do you have any idea about this? Thanks in advance! --Danny

MediaWiki internal error
I'm also getting the MediaWiki Internal error.

Seems like this has been a problem for a few folks, I've tried the (now removed) instructions posted earlier for 5.3 & 1.11, but that didn't help either. I'm trying with a fresh copy of 5.9 and 1.11. See 'upgrade to 5.7 gives error message' and 'Error after installing module' above for others having this issue.

Any ideas would be much appreciated. Cheers.