Re: [Phplib-users] php4 session fix, and some thoughts

[Lindsay H. <fmo...@fm...>]

Thus spake Maxim Derkachev on Wed, Jan 22, 2003 at 02:38:25AM CST
> Hello, Joe,
> 
> Wednesday, January 22, 2003, 3:52:51 AM, you wrote:
> JS> To make sure I understand - The auto_init file is included with every
> JS> pageview when using the session4.inc class.  Using the session.inc it is 
> JS> only included on session creation.  This is because the value of sess->in 
> JS> is lost so the conditional in page4.inc fails.
> 
> Right. And I don't consider it a bug. I described this behavior when
> released the very first version of the session4[_custom] in the readme file
> next to the classes (still there, quite outdated, but most of it is still true).
> The $sess->in is not saved with session because the PHP4 sessions
> don't allow saving a member of an object without saving the whole
> object. We don't need to save $sess object with the session, don't we?
> It is the one of the few differences between Kristian's Session and
> the new Session classes with PHP4 session support.
> The problem can be easily fixed in the setup.inc file (or page.inc, or
> somewhere else). The only thing You need is to register any other variable
> (besides the member of the $sess object) and use it as a marker, or to
> check variables in the setup.inc with is_registered() before initialization.

Either $sess->in must truly reflect whether or not auto_init has been
executed, as per the API, which also spec's that auto_init "is included and
executed exactly once" per session, or else the API has to change, which may
break things in existing applications code.  If the API is going to change
this radically, then suitable documentation MUST be provided for those of us
using phplib in real-world business applications.  Knowing about these
changes allows us to avoid breaking websites - and customer confidence.  

If $sess->in, and its expected behavior, is to be dropped as part of the
API, then at very least page4.inc needs to change so as to rely on some
other mechanism to determine whether or not auto_init has been executed. 
Loss of the expected function of $sess->in may not be a bug, and we can work
with it if the developers intend to change the API and document the changes,
but changing the expected behavior of auto_init is another matter altogether.

I submitted a couple of patches which provide for restoring the published
behavior of the auto_init script (execution exactly once per session).  One
of these (the 2nd) also restores some of the expected behavior of $sess->in,
although my solution is compromised somewhat in that it behaves more like a
global variable than an instance variable, and isn't unique in each class
which may be derived from Session, although this could be addressed.  At
least my customers' shopping carts will work when I switch over to using
php4 session management :-)

Par 2.2 - Auto_init issues, in your README puts the responsibility for
checking for previous execution of the auto_init file back into user
application space.  Please consider that this puts quite a burden on hosting
and design providers who may host dozens of sites which depend on the
publised behavior of the auto_init file.  Making the necessary changes in
phplib so as to support $sess->in, or at least making sure that page_open
behaves as expected with regard to auto_init, will save a lot of us a lot of
headaches and support calls.  There's no overriding reason _not_ to do this,
as far as I can see, and your README makes no argument for the change.  If
there are reasons for it which aren't stated, please tell me.

IMHO, the first responsibility of the phplib API is to the user application
space, and one of the functions of the session class is to provide a
consistent API that insulates the user application space from underlying
changes in the session storage structure or technology.  Changing the API in
such a way as to make it no longer upward compatible with existing
applications is both unnecessary and ill advised.  Adding features which
provide access to hooks in php4 session management is good, and will be well
appreciated, but there's no reason to change the existing API so as to break
something already in place, expecially since there are options available (as
in the patches I submitted) which allow the developers to NOT do this.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |