From: Christopher E. B. <chr...@ac...> - 2007-11-02 08:43:24
|
Paul Lesniewski wrote: > You want to use all the options to bludgeon this problem to death. > :-) Yes > I think you only need one, done correctly. SM is not > inconsistent (disorganized, yes) with where and how the session is > started, at least for pages served to a logged-in user. They all > include validate.php first, and the rest is as we have already seen. > Putting the code in config_local will make this work everywhere, then, > except on the login page where we do some intentional session > clean-up, so that's the only place we need to reset the handlers per > the PHP bug. Putting the code in sqsession_is_active() not only tries > to set the handlers too many times (including times when the session > is currently active), but it means running extra code over and over > for people who don't use custom handlers (the vast majority of SM > users). Therefore, unless anyone can point to a problem with the most > recently proposed patch (to login.php), that's what will be added, and > it should in fact provide full support for anyone who wants to > implement custom session handlers inside of SM without changing any > PHP settings. > > - Paul I am fine with the login.php mod instead of sqsession_is_active(), but I would still suggest that the documentation refer to setting only the $custom_session_handler array in config_local.php The session handler functions and the original calls to session_module_name and session_set_save_handler are better done in a php preload. config_local.php or a require from config_local works, but the fairly common practice of using a preload makes sure that no session functions can be called before session handler setup. -- ------------------------------------------------------------------------ Christopher E. Brown <chr...@ac...> desk (907) 550-8393 cell (907) 632-8492 IP Engineer - ACS ------------------------------------------------------------------------ |