-----Original Message----- From: mediawiki-l-bounces@Wikimedia.org [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of Brion Vibber Sent: Saturday, April 30, 2005 11:08 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] AuthPlugin always fails withfatal erroron initialauthentication
Carlton B wrote:
Well, in this case I guess we've just got different things
going on, because
I didn't override AuthPlugin::initUser and I didn't modify LoginForm::initUser or tamper with SpecialUserlogin.php in any way. The only way I could get AuthPlugin to do an autocreate without throwing the fatal error was by overriding AuthPlugin::initUser to return
the reference
to the user it was passed.
Can you confirm that you made no other changes to the code? Have you followed the execution path to make sure there's no other place that's using the return value? Have you confirmed that the return value is used by checking for the returned value?
To confirm this, I unpacked the 1.4.2 tar file in a completely separate subdirectory and added back in only my AuthPlugin extension, LocalSettings.php file, and a graphics file. The pristine version continued to yield the error. A recursive diff showed that the non-erroring version's copy of SpecialUserlogin.php contained a seemingly trivial debugging edit. After doing some more focused testing on a good night's sleep, in versions 1.4.2 and 1.4.3, I can say that I was incorrect and you were correct in saying the return value from AuthPlugin::initUser's subclass was related to this problem. Now, before you toss your hat in the air and say "Aha!", let me tell say that what I did find is troubling.
This is the change: Below line 254 of SpecialUserlogin.php, I had added the following line which became line 255. $rather_unique_varname_bznksjx = $u; // fairly certain this var name won't conflict with anything else.
There is no other difference in the file, and of course I never used the rather variable anywhere else. I can reproduce the problem at will by adding and removing this single line. I can't give a good technical explanation of why I did it or why it makes AuthPlugin work for me. All I know is that I am highly, highly suspicious of PHP 4's scoping and references. When I noticed the variable $u used both explicitly and as a reference all throughout SpecialUserlogin.php, I suspected PHP might have mishandled transitioning between scopes. Thus I thought it would be healthy or at least harmless to explicitly reference the $u variable at least once in LoginForm::processLogin. According to what I know of PHP internals (not much at this point), this change should have had no effect. But it did, and it worries me not to know why.
Perhaps it's my version of PHP. I am on php 4.3.11.
Are you using any PHP accelerator plugins? If so, which and what versions?
I am not sure how to determine this, but my host's feature page says we are using the Zend optimizer, and phpinfo() shows this information: This program makes use of the Zend Scripting Language Engine: Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St. Petersburg, by Dmitry Stogov with Zend Extension Manager v1.0.6, Copyright (c) 2003-2004, by Zend Technologies with Zend Optimizer v2.5.7, Copyright (c) 1998-2004, by Zend Technologies
Is this interface widely referenced elsewhere, can I safely rename it on
line 254 of
SpecialUserLogin.php and then change it to the same in my AuthUser extension?
Have you tested this? Does it in fact help?
I tested this and it had no effect. The difference was explicitly referencing the $u variable right after line 254 of SpecialUserlogin.php.
This would be a hard nut to crack except maybe for somebody who really knows PHP internals. I've already put too many hours into this problem, so I'm not putting any more time into it, and I wouldn't expect anyone else to either. Maybe we'll just pick up from this point if somebody else runs into the same thing.
-Carlton