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

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 )

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.  )