phplib-users — A list for users of phplib to talk / discuss phplib

Re: [Phplib-users] Release: phplib 7.4-pre2

[Marko K. <M.K...@os...>]

Chris,

> I think "we" pretty much decided by consensus among those who participated
> that the php-lib-stable tree was where all releases would come from, and
> that the current php-lib tree was far too full of unknowns to be usable.
Yes, I remember the discussion.

> Phplib developers can get ideas from things in php-lib, but I also believe
> the consensus was that we needed to start a new development tree once we
> had a real release (not a beta) from the -stable tree.  The CVS tress are
> definitely in need of cleaning and organizing.
Yes, I know as well, I think I was one of the first who asked to take the
snapshot into CVS to have a better control of what is going on, though I
am definitely not a phplib-developer.

The ONLY thing which made me nervous was that the announcing post from Joe
which started this thread didn't give that information that one has to use
phplib-stable. Someone reading only that post, who didn't follow the list
and wouldn't know about the final decision to use the stable tree, would
probably try to get the sources from phplib (the developer tree). Don't
you think?

That's all what I wanted to note.

OK, I better stop spamming everybody on this list with my useless remarks
about this. I don't want to blame anybody for something! I found the
sources myself, understood why it had to be done this way to keep
everything consistent, since that's what was the intention: to get rid of
this uncomfortable snapshots.

If nobody else was irritated than I shut up anyway. Never mind. I think we
are all happy that phplib develops and got more alive during the past
year. Good to see that finally CVS keeps control over the sources again.


Marko

Re: [Phplib-users] Release: phplib 7.4-pre2

[Chris J. <ch...@ch...>]

On Mon, Jan 27, 2003 at 04:01:06PM +0100, Marko Kaening wrote:
> Hi Joe and others,
> 
> joe steward wrote:
> > It is the same as the cvs snapshot.  The release is taken straight from
> > the php-lib-stable cvs.
> 
> Is that the reason why the branching was made in the phplib-stable cvs
> tree and not, as one might expect, in the phplib tree?
> 
> I thought we settled to use the phplib repository for development and the
> phplib-stable only for really stable stuff.

Marko,

I think "we" pretty much decided by consensus among those who participated
that the php-lib-stable tree was where all releases would come from, and
that the current php-lib tree was far too full of unknowns to be usable.

Phplib developers can get ideas from things in php-lib, but I also believe
the consensus was that we needed to start a new development tree once we
had a real release (not a beta) from the -stable tree.  The CVS tress are
definitely in need of cleaning and organizing.

-- 
    ..chris

Re: [Phplib-users] PHPLIB with register_globals off

[Chris J. <ch...@ch...>]

On Sun, Jan 26, 2003 at 07:40:40PM -0700, Carl Youngblood wrote:
> Hello,
> 
> I am wondering if anyone on this mailing list has modified PHPLIB to
> work properly with register_globals turned off.  In fact, for me the
> ideal solution would be to have a library like PHPLIB with the ability
> to use native PHP4 sessions (which I've heard has already been
> developed) as well as seamless support for register_globals being turned
> off.
> 
> With as nice of a tool as PHPLIB is, I'm surprised not to find very much
> information about this.
> 
> Thanks,
> Carl Youngblood

Carl,

The most recent release of PHPLIB (phplib-7.4-pre2) both supports
register_globals turned off (for most classes, including all the
major ones), and PHP4 native sessions (via auth4,page4, user4.inc).

Download it here:

	http://sourceforge.net/projects/phplib/

-- 
    ..chris

Re: [Phplib-users] Sharing sessions between domains

[Peter C. <pe...@kr...>]

A very boring question, obviously!

For the record, I sorted by problem by changing session4::start (code at end of message). The main change was to move the call to session_id to before the session_start, so that the session id can be forced - the session Id is pulled from $_GET if present. There's no need to change fallback_mode.

Cheers

Peter


Modified function:

  /**
  * Start a new session or recovers from an existing session
  *
  * @return boolean   session_start() return value
  * @access public
  */
  function start() {

    if ( $this->mode=="cookie"
        && $this->fallback_mode=="cookie")  {
      ini_set ("session.use_only_cookie","1");
    }

    $this->set_tokenname();
    $this->put_headers();

    // We have been provided with a session ID (used when traversing domains)
    // - moved before session_start to allow id to be forced (PAC 27Jan03)
    if (isset($_GET[$this->name]))
      $this->id = session_id($_GET[$this->name]);
    else
      $this->id = session_id();
      
    $ok = session_start();
#    $this->id = session_id(); //PAC moved before session_start

    // If register_globals is off -> restore session variables to global scope
    if(!(bool) ini_get('register_globals')) {
      if(is_array($_SESSION)) {
        foreach ($_SESSION as $key => $value) {
               global $$key;
          $$key=$value;
        }
      }
    }
    return $ok;
  } // end func start

[Phplib-users] Release: phplib 7.4-pre2

[Marko K. <M.K...@os...>]

Hi Joe and others,

joe steward wrote:
> It is the same as the cvs snapshot.  The release is taken straight from
> the php-lib-stable cvs.

Is that the reason why the branching was made in the phplib-stable cvs
tree and not, as one might expect, in the phplib tree?

I thought we settled to use the phplib repository for development and the
phplib-stable only for really stable stuff.

But okay, since the dev-snapshot is actually quite stable, at least for my
conditions here, one might be able to live with it and seen at the history
of all the files and the order in the phplib-stable tree (in comparison to
the overcrowded phplib tree) it's a good thing to do so.

Only that it surprised me that nowhere was explicitely noticed that one
should go for the stable tree.

Sorry to bother this list with this topic.

Perhaps I am just too picky.



Marko

[Phplib-users] PHPLIB with register_globals off

[Carl Y. <ca...@yo...>]

Hello,

I am wondering if anyone on this mailing list has modified PHPLIB to
work properly with register_globals turned off.  In fact, for me the
ideal solution would be to have a library like PHPLIB with the ability
to use native PHP4 sessions (which I've heard has already been
developed) as well as seamless support for register_globals being turned
off.

With as nice of a tool as PHPLIB is, I'm surprised not to find very much
information about this.

Thanks,
Carl Youngblood

[Phplib-users] =?hz-gb-2312?q?30=CD=F2=D3=CA=D6=B7100=D4=AA=A3=AC=CB=CD=C8=ED=BC=FE=D2=BB=CC=D7?=

[<ti...@ge...>]

=C4=E3=C8=E7=B9=FB=D0=E8=D2=AA=D7=F6=B9=E3=B8=E6=A3=AC=C7=EB=C4=E3=BD=AB=C4=E3=
=CB=F9=D2=AA=D0=FB=B4=AB=B5=C4=B2=FA=C6=B7=BA=CD=B6=D4=CF=F3=B8=E6=CB=DF=CE=D2=
=A3=AC=CE=D2=BB=E1=CE=AA=C4=E3=B6=A8=D6=C6=C4=E3=CB=F9=D2=AA=B5=C4=D3=CA=D6=B7=
=A3=AC=BC=DB=B8=F1=A3=BA30=CD=F2=D3=CA=D6=B7100=D4=AA=A3=AC=CB=CD=C8=ED=BC=FE=
=D2=BB=CC=D7=A3=AC=D2=BB=C8=D5=C4=DA=BD=BB=BB=F5=A3=AC=CE=D2=B5=C4=D3=CA=CF=E4=
=CA=C7u...@ya...
>=C7=EB=C1=F4=C4=E3=B5=C4=D3=CA=CF=E4=B5=D8=D6=B7=D2=D4=B1=E3=C1=AA=CF=B5=A3=
=AC=C8=E7=B9=FB=C4=E3=B2=BB=D0=E8=D2=AA=BF=B4=B5=BD=CE=D2=B5=C4=B9=E3=B8=E6=A3=
=AC=C7=EB=B7=A2=D3=CA=BC=FE=B5=BD=D3=C3=BB=A7=C3=FBusa123468 @ yaoweb.com=D6=
=D0=D2=AA=C7=F3=B3=B7=B3=FD=C4=E3=B5=C4=D3=CA=CF=E4=B5=D8=D6=B7=A1=A3 =D4=DA=
=D6=F7=CC=E2=D6=D0=CC=EE=D0=B4=C4=E3=B5=C4=D3=CA=CF=E4
>do you have products to sell in net ,please contact with me .i can find
>300000 emailaddress for you only 10$ ,and i will sent it with a =
emailsendersoft to you,if you need please sent a mail to me ,my email: =
usa...@ya...
>if you want to remove your emailaddress pleses sent email to =
username:usa123468 its yaoweb.com and full in your emaiaddress on =
subject.then i will delete it 
   

[Phplib-users] Sharing sessions between domains

[Peter C. <li...@kr...>]

Hi

I need some help:

I'm working on a multilingual site that has different domains depending on whether the content is english or french (say english.com and francais.com). I want to allow a user who has logged-in in one domain to remain logged-in (and keep their session variables) when they move to the other. I'm having problems keeping the session-ID between domains (using session4, auth4).

I know this must have come up before... I've had a look through the archives and found a brief discussion of this in May '02 which talked about some of the issues (including security), but didn't give an example, which I clearly need!

My approach has been to get around the cookie domain issue by ensuring that when moving domains. the session id is included in the URL, and set $sess->fallback_mode to get. 

When I first move to the new domain, $sess->id appears to have been picked up OK from the URL (and my $auth preserved). But as soon as I move to another page, there's a new $sess->id, so I've lost my $auth info.... I've tried using $sess->id() for force the new Id, but that doesnt seem to help... so presumably, a cookie has been set (or not been set) somewhere.

What else do I need to do? Or, does anyone know a place where I can find an example?

Cheers

Peter



_________________
Peter Cruickshank

Re: [Phplib-users] php4pre2

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

Joe Stewart wrote:
> 
> 7.4pre2 was the first step to getting the newer code and functions 
> released.
> 
> We aren't going to release anything that is not checked into cvs.  The 
> -stable cvs had been in a testing freeze for months.  So it seems more 
> prudent to go ahead and release it and then commit the patches and go 
> through the testing cycle for release again.

Then  I suggest let's get rid of the snapshot. In the end the only 
difference shoud remain the auth.inc. isn't it? Thinking about API, I 
can add back, though in a different way, the cancel_login. What I doubt 
is wether to add it as 'just need the field for compliance', or 'need 
the field AND the functionality'?

Re: [Phplib-users] php4pre2

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

> 
> It seems that this current discussion is the only complaint so far with 
> 7.4pre2.  Does anyone have anything else that hasn't been identified?

Also $auth->auth[error] was added in snapshot to better hold error messages

G

Re: [Phplib-users] php4pre2

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

> It seems that this current discussion is the only complaint so far with 
> 7.4pre2.  Does anyone have anything else that hasn't been identified?

the whole part about checking already submitted forms, that starts with:

< ######################################################
< ######## check for already submitted formids #########
< ######################################################
<     global $sess, $used_formids;
....

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

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

Thus spake Giancarlo on Fri, Jan 24, 2003 at 04:13:25PM CST
> >>This would probably work (although I haven't tested it either).  I think 
> >>it
> >>would be more scalable to make keeping track of session business the
> >>responsibility of the Session class rather than the effective constructor
> >>for the Page class, but if we're going this route, and $sess->in is to be
> >>depreciated, the above code could be simplified further still.
> >>
> 
> But why should it be deprecated! The fist time $sess->inis taken from 
> the code, from the included source. And from that moment on it will hang 
> onto another presistent variable, extra to the $sess object. And this 
> last persistent var will anyway set the $sess->in value, and it will be 
> transparent. And not deprecated.

To quote Spock, "this is logical".  As far as I'm concerned, there's no
reason to depreciate $sess->in.  It was Maxim Derkachev who suggested that
both $sess->in and the documented behavior of auto_init were going to go
away.  I see no reason at all to eliminate anything in the published phplib
API unless it's absolutely necessary, for technical reasons, to do so.

I can run a .COM file on a MS Windows box (the old < 64K executable format)
and the memory image of the program still contains a 256 byte Program
Segment Prefix with all the same stuff in it that was included when we were
using 8 bit computers with CP/M back in the late 70's and early 80's.  It's
generally useless, but the cost is minimal and it was left there to insure
upward compatibility of these old programs.  The published API for any
platform should get broken only in cases of absolute technical necessity,
and then it's done at the peril of the platform itself.

-- 
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    |                      |

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

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

> 
> Here's Gian's suggestion with session appended to the variable name.  
> Seems sess->get_id() really is an internal method.  Couldn't get it to 
> work using it.
> 

Yea. get_id tries to evince from where to get the id, depending on the 
mode/fallback mode and what is available at various places... ;-)

G

Re: [Phplib-users] php4pre2

[Joe S. <jo...@be...>]

On Fri, Jan 24, 2003 at 11:03:16PM +0100, Giancarlo wrote:
> 
snip!
> 
> in fact Joe I see now that 7.4pre2 has page4.inc included in prepend, 
> and page.inc included in prepend.php3, and both should have page.inc, 
> which comes from snapshot..

7.4pre2 was the first step to getting the newer code and functions 
released.

We aren't going to release anything that is not checked into cvs.  The 
-stable cvs had been in a testing freeze for months.  So it seems more 
prudent to go ahead and release it and then commit the patches and go 
through the testing cycle for release again.

It seems that this current discussion is the only complaint so far with 
7.4pre2.  Does anyone have anything else that hasn't been identified?

> same for local/local4: of more the latter only contains the 
> *session_custom class definition.
> 

true.  the only difference is that it contains an example of the 
session_custom usage.

Joe

> Gian
> 

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

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

>>This would probably work (although I haven't tested it either).  I think it
>>would be more scalable to make keeping track of session business the
>>responsibility of the Session class rather than the effective constructor
>>for the Page class, but if we're going this route, and $sess->in is to be
>>depreciated, the above code could be simplified further still.
>>

But why should it be deprecated! The fist time $sess->inis taken from 
the code, from the included source. And from that moment on it will hang 
onto another presistent variable, extra to the $sess object. And this 
last persistent var will anyway set the $sess->in value, and it will be 
transparent. And not deprecated.

Gian

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

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

> I don't see any problem with using simple global variables for this job as
> long as the name space is clearly identified and documented so as to avoid
> any such conflict.  If the API were to specify, for instance, that all
> variable names starting with $PHPLIB_INTERNAL (to use another name) are
> reserved, and that an application should never define such a variable, the
> problem of namespace conflicts would be effectively resolved.

The example I wrote would just work with classic phplib session. In fact 
I modified the page.inc from the snapshot, which is an unique page.inc 
for both. There is no need for two, and that one can still work for php3 
sites. Application still continue to use $sess->in in the extended 
class, and need not to worry about that new extra_session_object switch.

I think that we should try to minimize also the included files. I am 
pretty sure the snapshot has : the same local.inc included,  same 
page.inc (and with latest fixes), and they all seem to work from php3 to 
php 4.23. And this although there are now quite a few functions that did 
not even exist in php3. I think the whole snapshot, with the classic 
stable auth, should be rolled out...

in fact Joe I see now that 7.4pre2 has page4.inc included in prepend, 
and page.inc included in prepend.php3, and both should have page.inc, 
which comes from snapshot..
same for local/local4: of more the latter only contains the 
*session_custom class definition.

Gian

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

[Joe S. <jo...@be...>]

On Thu, Jan 23, 2003 at 01:45:00PM -0600, Lindsay Haisley wrote:
> Thus spake Joe Stewart on Thu, Jan 23, 2003 at 01:42:43PM CST
> > 
> > It does not 
> > mention the sess->in that I could find.
> 
> It's listed as an internal instance variable of the Session class in the
> current documentation.
> 

thanks.  When I build the documentation, it doesn't build those tables in 
documentation.txt, so I missed it.

Joe

> --
> 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    |                      |
> 

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

[Joe S. <jo...@be...>]

Variation on the theme:

On Thu, Jan 23, 2003 at 02:27:09PM -0600, Lindsay Haisley wrote:
> 
> This would probably work (although I haven't tested it either).  I think it
> would be more scalable to make keeping track of session business the
> responsibility of the Session class rather than the effective constructor
> for the Page class, but if we're going this route, and $sess->in is to be
> depreciated, the above code could be simplified further still.
> 

I played around some and these solutions seem to work OK.

> 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
> 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.
> 

Agree on your concerns for possible confusion and name collision.

Aren't session variables with the existing session3 class also global?

> 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.
> 


Here's Gian's suggestion with session appended to the variable name.  
Seems sess->get_id() really is an internal method.  Couldn't get it to 
work using it.

    $phplib_sess = "phplib_".$sess->id; 
    if(array_key_exists($phplib_sess, $_GLOBALS)) {
       $sess->in = 1;
    }
    ## Load the auto_init-File, if one is specified.
    if (($sess->auto_init != "") && !$sess->in) {
      $sess->in = 1;
      $GLOBALS[$phplib_sess]['id'] = $sess->id;
      $sess->register($phplib_sess);
      if (substr($sess->auto_init,0,1) == '/') {
        include($sess->auto_init);
      } else {
        include($_PHPLIB["libdir"] . $sess->auto_init);
      }
      if ($sess->secure_auto_init != "") {
        $sess->freeze();
      }
    }
      
Joe

> -- 
> 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    |                      |

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

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

Thus spake Giancarlo on Fri, Jan 24, 2003 at 04:26:45AM CST
> 
> 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.

PHP4 session management in phplib has to be alpha and beta until the
underlying API settles down and becomes stable.  It looks like this has
happened now, mostly, which is why I'm trying to install it on working
sites.

> 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...

Don't know about previous versions of php4.  I know, from the user comments
in the php docs, that you can't put a variable into the session data from
within a function or method unless it's declared to be global.  Inserting it
into the $_SESSION array apparently isn't enough.
 
> the $_PHPLIB array exists, and is not persistent.

This  name was just an example.  Any name could be used.  My point is that
some sort of easily recognizable name prefix needs to be reserved for use
with variables which are functionally internal to phplib, but because
they're being put under php4 session management, they have to be made
global, which puts them at risk of being duplicated in application space.

I did first consider using some simple variables, as in the patch suggestion
you posted, but went with something more complex so as to avoid, in as much
as possible, any conflict with application space varibles.

I don't see any problem with using simple global variables for this job as
long as the name space is clearly identified and documented so as to avoid
any such conflict.  If the API were to specify, for instance, that all
variable names starting with $PHPLIB_INTERNAL (to use another name) are
reserved, and that an application should never define such a variable, the
problem of namespace conflicts would be effectively resolved.

This isn't to say that someone _couldn't_ screw up and overwrite such a
variable in the global scope, but they would have been warned, and this is a
pretty easy rule to follow.  The solution isn't perfect, nor is it really
kosher from an OOP perspective, but from a practical point of view it's very
workable.

-- 
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    |                      |

Re: [Phplib-users] php4 session 4.[0.6-2.3]

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

Thus spake Giancarlo on Fri, Jan 24, 2003 at 05:07:00AM CST
> I have not clear what does work. Of course using $_SESSION where it 
> didn't exists as a suoperglobal, does not. But does using 
> $sess->register with reg_glob=off work with both 4.0.6 and 4.2.x?

I had less luck getting things into the php4 session storage using the
$_SESSION array than I did invoking $sess->register, which apparently does
the right magic to make this happen.  I didn't look into why this is, but it
worked, as it should, and since it's always better to go through the proper
class accesses than straight to the underlying API, I used this.

So yes, I think you're right.

-- 
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    |                      |

[Phplib-users] php4 session 4.[0.6-2.3]

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

I have not clear what does work. Of course using $_SESSION where it 
didn't exists as a suoperglobal, does not. But does using 
$sess->register with reg_glob=off work with both 4.0.6 and 4.2.x?

Gian

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.
> 

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

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

Thus spake Joe Stewart on Thu, Jan 23, 2003 at 01:42:43PM CST
> > ## Load the auto_init-File, if one is specified.
> >       $sess->register('phplib_sess_in');     #1
> >       if ($GLOBALS['phplib_sess_in'] == 1) { #2
> >          $sess->in =1;                       #3
> >          }                                   #4
> >       if (($sess->auto_init != "") && !$sess->in) {
> >         $sess->in = 1;
> >         $GLOBALS['phplib_sess_in'] = 1;      #5
> >         if (substr($sess->auto_init,0,1) == '/')
> >           include($sess->auto_init);
> >         else
> >           include($_PHPLIB["libdir"] . $sess->auto_init);
> >         if ($sess->secure_auto_init != "") {
> >           $sess->freeze();
> >         }
> >       }

This would probably work (although I haven't tested it either).  I think it
would be more scalable to make keeping track of session business the
responsibility of the Session class rather than the effective constructor
for the Page class, but if we're going this route, and $sess->in is to be
depreciated, the above code could be simplified further still.

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
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.

-- 
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    |                      |

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

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

Thus spake Joe Stewart on Thu, Jan 23, 2003 at 01:42:43PM CST
> 
> It does not 
> mention the sess->in that I could find.

It's listed as an internal instance variable of the Session class in the
current documentation.

--
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    |                      |

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

[Joe S. <joe...@us...>]

On Thu, Jan 23, 2003 at 06:11:14PM +0100, Giancarlo wrote:
> Is this too semple? untested.
> maybe one should use $_SESSION instead of $GLOBALS.
> 

FWIW this is more in line with what I had started myself.

Max - I understand not supporting the sess->in in the original release of 
session4.  However I think that supporting sess->auto_init is pretty 
important and as has been shown can be done with little overhead.
It is important to provide backward compatibility to phplib applications 
for now.  This is getting to be a soapbox issue and is turning people off 
from php and Zend.  Many applications are not custom built but instead 
distributed to be used on many different servers.

The documentation specifies how the auto_init should work.  It does not 
mention the sess->in that I could find.  So I'm much less concerned about 
using sess->in to accomplish the loading-once-per-session of the auto_init 
file.
 
Gian - it looks like you also applied the patch to allow a path for the 
auto_init file.  thanks.  This is a shortcoming of the session3 code.

thanks,

Joe

> ## Load the auto_init-File, if one is specified.
>       $sess->register('phplib_sess_in');     #1
>       if ($GLOBALS['phplib_sess_in'] == 1) { #2
>          $sess->in =1;                       #3
>          }                                   #4
>       if (($sess->auto_init != "") && !$sess->in) {
>         $sess->in = 1;
>         $GLOBALS['phplib_sess_in'] = 1;      #5
>         if (substr($sess->auto_init,0,1) == '/')
>           include($sess->auto_init);
>         else
>           include($_PHPLIB["libdir"] . $sess->auto_init);
>         if ($sess->secure_auto_init != "") {
>           $sess->freeze();
>         }
>       }
> 
> 
>  >
>  > ------------------------------------------------------------------------
>  >
>  > --- session4.inc	2003-01-20 18:52:26.000000000 -0600
>  > +++ session4.inc.fixed	2003-01-20 18:53:27.000000000 -0600
>  > @@ -11,6 +11,19 @@
>  >  * @access    public
>  >  * @package   PHPLib
>  >  */
>  > +
>  > +class CurrentSession {
>  > +	var $ai_done = false;
>  > +	
>  > +	function set_ai_done($val) {
>  > +		$this->ai_done = $val;
>  > +	}
>  > +	
>  > +	function get_ai_done() {
>  > +		return $this->ai_done;
>  > +	}
>  > +}
>  > +
>  >  class Session {
>  >
>  >
>  > @@ -43,8 +56,8 @@
>  >    * Marker: Did we already include the autoinit file?
>  >    *
>  >    * @var  boolean
>  > -  */
>  > -  var $in = false;
>  > +  */
>  > +#  var $in = false;
>  >
>  >
>  >    /**
>  > @@ -147,6 +160,20 @@
>  >    *
>  >    * @see  name()
>  >    */
>  > +
>  > +  function get_auto_init_done() {
>  > +   	$sob = "sob_".session_id();
>  > +    global $$sob;
>  > +    return $$sob->get_ai_done();
>  > +  }
>  > +
>  > +  function set_auto_init_done($val) {
>  > +   	$sob = "sob_".session_id();
>  > +    global $$sob;
>  > +    $$sob = $_SESSION[$sob];
>  > +    $$sob->set_ai_done($val);
>  > +  }
>  > +
>  >    function Session() {
>  >      $this->name($this->name);
>  >    } // end constructor
>  > @@ -170,6 +197,14 @@
>  >
>  >      $ok = session_start();
>  >      $this->id = session_id();
>  > +
>  > +    if (!isset($_SESSION["sob_".session_id()])) {
>  > +    	$sob = "sob_".session_id();
>  > +    	global $$sob;
>  > +    	$$sob = new CurrentSession;
>  > +    	$this->register($sob);
>  > +    }
>  > +
>  >
>  >      // If register_globals is off -> restore session variables to 
> global scope
>  >      if(!(bool) ini_get('register_globals')) {
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  > --- page4.inc	2003-01-20 17:21:23.000000000 -0600
>  > +++ page4.inc.fixed	2003-01-20 17:37:24.000000000 -0600
>  > @@ -51,8 +51,8 @@
>  >      }
>  >
>  >      ## Load the auto_init-File, if one is specified.
>  > -    if (($sess->auto_init != "") && !$sess->in) {
>  > -      $sess->in = 1;
>  > +    if (($sess->auto_init != "") && !$sess->get_auto_init_done()) {
>  > +      $sess->set_auto_init_done(1);
>  >        include($_PHPLIB["libdir"] . $sess->auto_init);
>  >        if ($sess->secure_auto_init != "") {
>  >          $sess->freeze();
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users