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

[Giancarlo <gia...@na...>]

> I do have some concern with implications of the fact that the global name
> space must be used to reference all persistent data under php4 session
> management.  I think there needs to be a naming convention established for a
> reserved global name space in phplib.  For instance, we might say that all
> variables which phplib uses for its own internal record keeping must start
> with $_PHPLIB or something similar.  This could be part of the published API

There is an unresolved problem with phplib and php4 session wether it's 
  earlier than 4.2 (? not sure), when $_SESSION was introduced. So we 
have a session4 class that is OK with php4 session from version 4.2(?) 
on, but not earlier. But in this all, I think adopting *both* $GLOBALS 
&& $_SESSION (even if $_SESSION didn't exist at that time) should still 
work, but couldn't find time to try it yet 'cause for testing I need 
both 4.06 and 4.23 on.
Am I wrong to think that if we'd globalize all persistent vars as phplib 
did, we could be quite well off of this problem? I mean, if we'd always 
used $GLOBALS, and keep it always paired with $_SESSION  we shouldn't 
have any problem with both 4.06 and 4.23... at least on the paper... for 
incumbrant as it may be, $GLOBALS was already there before $_SESSION, 
and the latter is only a new $GLOBALS-like array...


the $_PHPLIB array exists, and is not persistent. There is already a 
phplib_formid that is used to prevent reposting via a backbutton. And 
there is the $sess->auth array, so important. I agree there should be a 
rule. There was also the $sess->pt var, used to double check the total 
number of persistent vars...


> so that applications could avoid tromping on internal variables.  It's
> concievable, considering the above patch, that someone might write an app
> that unknowingly used the name $phplib_sess_in for a global variable.
> 
> This is what I was trying to do by encapsulating the auto_init flag in a
> class of its own whose objects were identified with session_id().  As I
> noted, this may be overkill.  I did consider a solution as simple as the
> above patch.
>