Tags:
create new tag
view all tags

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

Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2004-08-16 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.