Bug: initializeUserHandler now broken
I believe the recent change to
initializeUserHandler
can't work as this call is done before plugins are initialised. Whilst it is good to move away from the hard coding of the
SessionPlugin
name, we will need another way of initialising plugins, as the existing initialisation passes the user information, which you won't know when you call a
SessionPlugin.
Test case
- Install the SessionPlugin.
- Add %WIKINAME% to a page
- In
view
(not authview
) you should see your Wiki username, but you won't with recent changes to Plugin.pm
Environment
TWiki version: |
30 Dec 2002 |
TWiki plugins: |
SessionPlugin |
Server OS: |
|
Web server: |
|
Perl version: |
|
Client OS: |
|
Web Browser: |
|
--
JohnTalintyre - 04 Jan 2003
Follow up
That is a bug indeed, introduced as part of
MorePluginHooks. Not sure how this can be fixed in a clean way. There is a chicken-and-egg problem:
- The Plugin initialization depends on the Preferences initialization
- The Preferences initialization depends on the user initialization
- The Plugins::initializeUserHandler depends on the login user name
One possible solution is to split up the Preferences initialization into two parts. Then it is possible to do this sequence:
- Init Preferences without user
- Init Plugins
- Call Plugins::initializeUserHandler
- Init Preferences with user
That should work but does change the spec: The user is not initialized at Plugin initalization time, which could break a Plugin that depends on the user info (e.g. to get a user preference at init time).
May be a correct solution is that the Plugins::initializeUserHandler checks each Plugins if one exposes an initializeUserHandler. If yes, initialize just that Plugin and call initializeUserHandler.
Opinions?
--
PeterThoeny - 05 Jan 2003
I think you are on the right lines. If we were starting from scratch then an init and later a user initialisation would make sense, but I think we should preserve compatibility with existing plugins. It might be cleaner to have:
- Init plugins that include
earlyInitialize
- Deal with preferences
- Init plugins as currently.
--
JohnTalintyre - 08 Jan 2003
I've got most of a cleaner solution for this, but I suggest this waits for the
CairoRelease and for now we go back to hard coding the reference to
SessionPlugin
, it's not so bad as you can only really have one plugin performing this function.
--
JohnTalintyre - 18 Jan 2003
Fix record
For the
BeijingRelease I reverted the code back to the old spec. John, could you test this out?
A clean solution needs to be worked out in the
CairoRelease. (Therefore the bug is still open)
--
PeterThoeny - 21 Jan 2003
The reversion works fine.
--
JohnTalintyre - 21 Jan 2003
Guys, just a big thank you for actually documenting this problem. Ive been tearing my hair out (and trust me, I dont have many folicles to spare...) for the last day or so trying to track down why I was having problems with my new skin & sessionplugin.
After upgrading from the the Dec beta to the final release everything is working.... Phew...
--
JohnCavanaugh - 03 Feb 2003
I don't understand. My
TWiki:Plugins/SmartSessionPlugin does not require any fix (though it's upsetting that I have to call it
SessionPlugin
since BeijingRelease has that hard coded as the only session handler).
As long as _init_authuser inside
TWiki:Plugins/SmartSessionPlugin is called
first there's no problem with the current release. Granted, it would be nice for
initUserHandler
to do this at the appropriate time, but is it necessary?
All I'm saying is that it seems silly to worry about changing TWiki to accomodate
TWiki:Plugins/SessionPlugin as
TWiki:Plugins/SessionPlugin seems to be in a poor state. The
TWiki:Plugins/SmartSessionPlugin is intended to be a complete rewrite and replacement for
TWiki:Plugins/SessionPlugin.
And by the way,
SmallTyposInPluginsPM should probably be something that's fixed. It's related to this bug. It's not a big deal though.
--
TedPavlic - 17 Jul 2003
I have a proper fix that allows a plugin of any name to work. Extra code is needed as this special plugin call must be done at a point earlier in the code than where plugins are initialised.
--
JohnTalintyre - 19 Jul 2003
I'm just finishing off some final testing then fix will be in. A session plugin will have to define an extra function. More soon.
--
JohnTalintyre - 25 Aug 2003
The bug responsible for this topic also causes problems with session plugins and
SpeedyCGI. This is discussed at
SmartSessionPluginDev.
The only way to make session plugins work with modperl/SpeedyCGI/etc. is to put all of the session initialization functions
within initializeUserHandler, which makes little sense and is purely a hack.
Having a way to initialize the session plugin (perhaps by forcing the initPlugin of the session plugin before initializeUserHandler is called) very early is very important.
Will the fix that's going into
CairoRelease make it so that session plugins can finally work with
SpeedyCGI without hacks?
--
TedPavlic - 02 Sep 2003
CVS updated. Note new earlyInitPlugin method in
DefaultPlugin and
SessionPlugin
--
JohnTalintyre - 04 Sep 2003
Can you have a look at
LoginShownAsGuest? I think this is due to these code changes, in a TWiki site not using any session plugins.
--
RichardDonkin - 22 Sep 2003
Patch supplied in
LoginShownAsGuest has been applied.
--
JohnTalintyre - 23 Sep 2003
SmartSessionPlugin has a bug under Cairo. See its Dev page for a fix.
--
MartinCleaver - 12 Apr 2004
I'm going to assume that this issue is done and finished. If there are any new reports, please start a new
BugReport.
--
SvenDowideit - 24 Jun 2004