Extension talk:AuthDrupal

Drupal links in MediaWiki
Hi everyone!, I hope somebody can help me to solve this. I'm new with mediawiki and drupal, right now, i have an AuthDrupal working with both. The problem is at the top of my mediawiki screen, where you have your username, your talk, your preferences, etc. When a user came into the mediawiki he has two links at the top "LOG IN" and "LOG OUT", when only should appear LOG IN, because the user is not logged. I repeat, i'm new in this, so will be appreciated if you can give me a hand! :).

Thanks!

--Mauro ptt 12:52, 15 May 2007 (UTC)

Drupal 5.1: working, redirects not working
It currently works with drupal 5.1. However, is it possible to do this: when an anonymous user tries to edit a wiki page, he logins in and be redirected to the wiki page he was trying to edit. Currently upon login, it goes to drupal frontpage.

Thanks!
 * If someone can point me in the right direction on doing this on the Drupal side, I'd be interested to try implementing it. I know very little about Drupal at this point, so I have no idea off hand. Thinkling 15:44, 23 March 2007 (UTC)

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

NEW PROBLEM
from Paul Coghlan

I did some testing on the whole issue of being logged in or logged out in Drupal and Mediawiki taking into account the 'Remember Me' feature and the user powering of their computer. It appears that selecting the 'Remember Me' checkbox in Drupal is having an impact. I suspect this changes values in the cookies.

TEST1 I logged into Drupal with 'Remember Me' turned off. I went to MW and confirmed I was logged in. I shut the browser and re-opened it, Drupal correctly had me logged out but MW still had me logged in. This is a bug. You might want to hide the 'Remember Me' checkbox and default it to yes to sidestep the issue for now.

I cleared all cookies and did it again, this time rebooting instead of just shutting the browser. Same result. Drupal had me logged out and MW had me logged in.

TEST2 I logged into Drupal with 'Remember Me' activated. I went to MW and confirmed I was logged in. I shut the browser and re-opened it, all OK. I rebooted the computer and check again, all OK. In each instance everything appeared to be fine. Both Drupal and MW remembered that I was logged in and I couldn't find any difference between them.

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

Dependency on mcrypt module
Mcrypt is not available on CentOS Linux, so I'm unable to run AuthDrupal. Neither Drupal nor MediaWiki uses the php-mcrypt extention. Why is it then required for AuthDrupal (crypto.php)?

I would appreciate if it can be removed/ replaced.


 * If the cookie content were in plain text, authentication would be completely spoofable and anyone could log in as anyone else, so complete removal is not an option. Can you suggest an alternative? I'm on other projects right now and don't have the bandwidth to chase this myself, sorry. Thinkling 22:04, 10 May 2007 (UTC)


 * UPDATE: here is a longer answer I wrote in an email. Thinkling 22:53, 24 April 2008 (UTC)


 * The way AuthDrupal is set up, some kind of reversible encryption is needed. This is because it should not be possible for the user of the browser to spoof the name of the user who was authenticated. If you set the cookie in plain text, then anyone could pretend to be anybody in the wiki.


 * As far as I know, there's nothing in PHP that's present on all systems--mcrypt seems to be the most common thing. crypt and md5 do not have matching decryption.


 * If you're comfortable with this sort of thing, it may be easy for you to set up PHP to be called through fastcgi rather than as an apache module, and then compile your own PHP that includes mcrypt. But if you have not done that before, I wouldn't go there. :-)


 * One alternative is to find straight PHP code for two functions to implement encryption and decryption and use them in crypto.php to replace mcrypt; I'm sure there are examples out there; whether they're good is a separate question. How robust you want it to be depends entirely on whether you think your site might attract a clever attacker.


 * Another alternative, if you're comfortable hacking PHP/SQL, is to create an extra table in your DB, and have AuthDrupal store a pair of (username, crypt(username)) in the DB. Then instead of storing the encrypted username, store the hash of the username in the cookie, and at the MW end query the DB to look up the username from its hash. You don't want to use md5 for this, since it is easily cracked with brute force checks AFAIK.


 * Sorry I don't have a simple answer for you. If you come up with a solution, please post it.

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 )

loadFromSession private
MW 1.10 gives this error message: Fatal error: Call to private method User::loadFromSession from context '' in /home/jail/home/gtisza/public_html/test/extensions/AuthDrupal/AuthDrupal.php on line 157

Replacing $tmpuser->loadFromSession; with $tmpuser->load; in AuthDrupal.php line 157 fixes this. --Tgr 22:26, 18 July 2007 (UTC)


 * This is now addressed in 0.3.2 Thinkling 23:36, 29 July 2007 (UTC)

AuthDrupal.php missing from AuthDrupal-0.4.tgz
Found and tried to install AuthDrupal 0.4 today. The package did not contain a file named AuthDrupal.php, however.

I downloaded the previous version (v3.2) and it contains AuthDrupal.php.


 * WHOOPS! That should be fixed now--sorry 'bout that Thinkling 15:20, 31 July 2007 (UTC)

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