-----Original Message-----
From: mediawiki-l-bounces(a)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