Thread: [Phplib-users] php4 session fix, and some thoughts
Brought to you by:
nhruby,
richardarcher
From: Lindsay H. <fmo...@fm...> - 2003-01-21 01:23:32
Attachments:
session4.inc.diff
page4.inc.diff
|
My shopping carts were broken using phplib with php4 session management, so I found the problem and fixed it. Patches against phplib-7.4-pre2 are attached. Basically, the instance variable $sess->in wasn't being saved across sessions, and Joe Stewart noted as much in his code comments. setup.inc was being run on each page access, so any stored information was getting wiped out since $cart->start(), in my setup.inc, ran each time a page was loaded. The underlying problem is that phplib session management no longer instantiates a session class with all the public and private instance variables needed by the API. While the $sess object stored in $_SESSION can invoke class methods from the underlying class definition, there's no ready way to store instance variables. Joe and others have fixed some of these, of course. To get around this, I defined a class, CurrentSession, and an instance object of _this_ class is stored in the $_SESSION array. An instance of CurrentSession can hold whatever instance variables the session requires and methods in the $sess object can be used to retrieve them. The CurrentSession instance object is named "sob_".session_id(), which may be overkill, but will definitely insure uniqueness. Rather than using the $sess->in instance variable, I defined a couple of methods, $sess->get_auto_init_done() and $sess->set_auto_init_done() which do much the same thing and require only a minor modification to page4.inc (for which a patch is also attached). I probably shouldn't have done this, since saving and restoring $sess->in could be done with a few lines of additional coding and this would preserve the API. This would require a working page_close() though, as noted below. There's a broader consideration here, and although I'm not familiar with all the details of the session class, I'll put forth a few ideas which seem to be extensible from the little work I've done here. IMHO, php4 session management shouldn't be thought of as a replacement in any way for phplib session management. In essence, php4 session management can be considered to be just another database engine with some added functionality such as session ID management, serialization and garbage cleanup. The object should be to preserve the published phplib session object API as much as possible to avoid breaking existing web applications which depend on phplib. Several things fall out from this: * The CurrentSession class could be expanded to include all necessary variables, both public and private previously exposed in the $sess class API. It might be good to put these into an array so that they could be extracted into the current session object with while(list(...) = each(...)) syntax. * The $sess->start() method should declare an object of CurrentSession, make it global, and register it. This is done in my patch. * page_open() should interate through the the variable array (or through all the instance variables) in the CurrentSession object and restore instance variables in the $sess object from this object in the $_SESSION array. My patch doesn't do this, but it wouldn't be hard to do. * page_close(), rather than being depreciated, should be retained and used to transfer $sess instance variables to the CurrentSession object stored in $_SESSION. I've simply defined a couple of $sess instance methods to do this as needed for the auto_init flag, but putting the required functionality into page_open() and page_close() would be a more general solution, and ought to be done to preserve the API. There aren't many of these variables, so this may be moot. Most, if not all of the variables in the older session.inc are static with respect to the lifetime of a session. * If session instance variables should, by and large, be considered as const varables, the CurrentSession class may be overkill, and a couple of global variables should do the trick. I first made a solution to the auto_init problem using a global variable rather than a global class, but the global class seemed to be a more general solution, and more elegant and scalable. I hope this helps. Joe, what do you think? If I find some time I'll work on this, but a bigger problem is getting phplib, php4 and apache2 to be friendly with each other :-) -- 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 | | |
From: Giancarlo <gia...@na...> - 2003-01-21 08:57:48
|
> Basically, the instance variable $sess->in wasn't being saved across > sessions, and Joe Stewart noted as much in his code comments. setup.inc was > being run on each page access, so any stored information was getting wiped > out since $cart->start(), in my setup.inc, ran each time a page was loaded. > > The underlying problem is that phplib session management no longer > instantiates a session class with all the public and private instance > variables needed by the API. While the $sess object stored in $_SESSION can Sorry. I didn't follow this. Why do you say that the $sess object is saved in the session? I am almost sure that $sess itself does not come from the session persistance. It is an object that is reinstantiated at every start from the source included, ant only its properties are deserialized from the storage... Gian |
From: Lindsay H. <fm...@fm...> - 2003-01-21 15:44:24
|
Thus spake Giancarlo on Tue, Jan 21, 2003 at 02:57:09AM CST > >Basically, the instance variable $sess->in wasn't being saved across > >sessions, and Joe Stewart noted as much in his code comments. setup.inc > >was > >being run on each page access, so any stored information was getting wiped > >out since $cart->start(), in my setup.inc, ran each time a page was loaded. > > > >The underlying problem is that phplib session management no longer > >instantiates a session class with all the public and private instance > >variables needed by the API. While the $sess object stored in $_SESSION > >can > > Sorry. I didn't follow this. > Why do you say that the $sess object is saved in the session? I am > almost sure that $sess itself does not come from the session > persistance. It is an object that is reinstantiated at every start from > the source included, ant only its properties are deserialized from the > storage... Portions of the session object, notably registered variables and whether or not the session as been previously initialized, are stored. Your point correct. The session object itself isn't stored. -- 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 | | |
From: Joe S. <joe...@us...> - 2003-01-22 00:48:00
|
On Mon, Jan 20, 2003 at 07:22:25PM -0600, Lindsay Haisley wrote: > My shopping carts were broken using phplib with php4 session management, so > I found the problem and fixed it. Patches against phplib-7.4-pre2 are > attached. > > Basically, the instance variable $sess->in wasn't being saved across > sessions, and Joe Stewart noted as much in his code comments. setup.inc was > being run on each page access, so any stored information was getting wiped > out since $cart->start(), in my setup.inc, ran each time a page was loaded. > I can't take credit for the code ( Max and maybe others deserve the thanks). I just moved the cvs around some. Sorry I don't have more time right now to help much with this. To make sure I understand - The auto_init file is included with every pageview when using the session4.inc class. Using the session.inc it is only included on session creation. This is because the value of sess->in is lost so the conditional in page4.inc fails. I filed a bug report: [ 672166 ] auto_init file included every page_view with session4 http://sourceforge.net/tracker/index.php?func=detail&aid=672166&group_id=31885&atid=403611 \ > The underlying problem is that phplib session management no longer > instantiates a session class with all the public and private instance > variables needed by the API. While the $sess object stored in $_SESSION can > invoke class methods from the underlying class definition, there's no ready > way to store instance variables. Joe and others have fixed some of these, > of course. > others (Giancarlo for one) fixed it in auth. > To get around this, I defined a class, CurrentSession, and an instance > object of _this_ class is stored in the $_SESSION array. An instance of > CurrentSession can hold whatever instance variables the session requires and > methods in the $sess object can be used to retrieve them. The > CurrentSession instance object is named "sob_".session_id(), which may be > overkill, but will definitely insure uniqueness. Rather than using the > $sess->in instance variable, I defined a couple of methods, > $sess->get_auto_init_done() and $sess->set_auto_init_done() which do much > the same thing and require only a minor modification to page4.inc (for which > a patch is also attached). I probably shouldn't have done this, since > saving and restoring $sess->in could be done with a few lines of additional > coding and this would preserve the API. This would require a working > page_close() though, as noted below. > I like the idea of preserving sess->in instead. page_close is already required again if you use register_globals off. thanks for tracking this down. Joe |
From: Lindsay H. <fm...@fm...> - 2003-01-22 01:15:56
|
Thus spake Joe Stewart on Tue, Jan 21, 2003 at 06:52:51PM CST > I can't take credit for the code ( Max and maybe others deserve the > thanks). I just moved the cvs around some. Sorry I don't have more time > right now to help much with this. I think it's under control. The patches I made work fine! > To make sure I understand - The auto_init file is included with every > pageview when using the session4.inc class. Using the session.inc it is > only included on session creation. This is because the value of sess->in > is lost so the conditional in page4.inc fails. That's right. The $in instance variable isn't saved off. Because it's an instance variable, apparently php doesn't allow one to declare it global, and if it's not global, it can't be saved in the php4 session data. The way around this is to create a global object and use page_open and page_close to move stuff between the $sess instance variable(s) and the global object. > I filed a bug report: > > [ 672166 ] auto_init file included every page_view with session4 > http://sourceforge.net/tracker/index.php?func=detail&aid=672166&group_id=31885&atid=403611 OK, thanks! I'll take a look at it. > > The underlying problem is that phplib session management no longer > > instantiates a session class with all the public and private instance > > variables needed by the API. While the $sess object stored in $_SESSION can > > invoke class methods from the underlying class definition, there's no ready > > way to store instance variables. Joe and others have fixed some of these, > > of course. > > > > others (Giancarlo for one) fixed it in auth. OK. Your stamp was on the RCS IDs, probably from doing CVS maintenance. > I like the idea of preserving sess->in instead. page_close is already > required again if you use register_globals off. You're right about this, of course. It's good that page_close isn't being dropped since it basically serves as a catchall page destructor funciton. My fix was kind of quick and dirty, and it did the job, but $sess->in is part of the published API and ought to be supported. The more I thought about it, the more I realized that this is the right approach. Shall I fix this and submit a patch? Will it reach people who may want or need it? > thanks for tracking this down. I did it for purely practical reasons :-) I have to make this stuff work. -- 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 | | |
From: Maxim D. <max...@bo...> - 2003-01-22 08:37:45
|
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. -- Best regards, Maxim Derkachev mailto:max...@bo... IT manager, Symbol-Plus Publishing Ltd. phone: +7 (812) 324-53-53 www.books.ru, www.symbol.ru |
From: Lindsay H. <fmo...@fm...> - 2003-01-22 21:02:52
|
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 | | |
From: Maxim D. <max...@bo...> - 2003-01-23 09:27:55
|
Hello, Lindsay, I did not promise that Session4* classes will be 100% compatible with the Session3 (I call it so). $sess->in is to be deprecated in the Session4, just because it is not possible to make it work the right way. That's why the API change. I suppose we should not bloat the code and/or mess with the global scope to solve the problem. It would be better just to change the documented auto_init behavior for the Session4. So, I consider it a documentation problem, that should be solved. Of course, You can not be sure that everything will work with the Session4 as it used to work with the Session3. Say, You might register something like $some_object->some_property with the Session3, while it simply won't work in the Session4 case, somebody could rely on Session3 serialize() data format, while it has nothing in common with the PHP4 session serialization format, and so on. -- Best regards, Maxim Derkachev mailto:max...@bo... IT manager, Symbol-Plus Publishing Ltd. phone: +7 (812) 324-53-53 www.books.ru, www.symbol.ru |
From: Lindsay H. <fmo...@fm...> - 2003-01-23 18:58:25
|
Thus spake Maxim Derkachev on Thu, Jan 23, 2003 at 03:28:36AM CST > Hello, Lindsay, > > I did not promise that Session4* classes will be 100% compatible with > the Session3 (I call it so). $sess->in is to be deprecated in the Session4, > just because it is not possible to make it work the right way. $sess->in is less a problem, in my view, than the behavior of auto_init. I don't reference $sess->in in any of my applications, but I make good use of auto_init and depend on its published behavior as supported through page.inc or page4.inc. > That's why the API change. I suppose we should not bloat the code and/or > mess with the global scope to solve the problem. It would be better just > to change the documented auto_init behavior for the Session4. Given the nature of php4 session management, I guess that any data that's going to be session oriented has to be global, but IMHO, doing whatever's necessary to preserve auto_init is worth it, and if the global variable is named something unique, then it's effectively private and shouldn't be a problem. The flag for it is only one byte! Hardly "bloat", although the overhead involved in making the flag unique and accessable will be a bit more. The very name of the feature, "auto_init", implies that it's a session initialization feature. If it's not to be supported, then we might as well put code in a page constructor method and be done with it and drop the auto_init/setup.inc feature altogether. IMHO, having a hook to a once-per-session function which we can set in applications space is highly useful and logical, and was wisely included by Kristian et al. If it's not supported in the ongoing phplib API, then I and everyone else who has a setup.inc which we depend on will get our applications broken and have to deal with it. If you go this way, I'm going to have to keep patches on hand to restore the expected behavior of auto_init, since I have several sites here that depend on it, as do others, I'm sure. I implore you to make the relatively small sacrifice in code and storage overhead required to at _least_ maintain the expected auto_init behavior, even if the $sess->in hook is depreciated and goes away. > So, I consider > it a documentation problem, that should be solved. That's the very least of it!! It's not even beta code until it's properly documented. There are a lot of people out here that use phplib as a tool on sites that people pay to have properly maintained by us. If we don't have the tools to work with, or the tools change so as to break rather than fix things, and we don't know about it, then we're in a pretty tough spot. > Of course, You can not be sure that everything will work with the Session4 > as it used to work with the Session3. Say, You might register > something like $some_object->some_property with the Session3, while it > simply won't work in the Session4 case, somebody could rely on > Session3 serialize() data format, while it has nothing in common > with the PHP4 session serialization format, and so on. As I said before, the first responsibility of the API is to the user application space, and keeping it consistent across upgrades in the underlying code has to be a primary objective of the developers. There are some things that will have to change, of course, however it's important to minimize the impact by preserving the API in as much as it's possible to do so. Supporting the expected behavior of auto_init is very doable and needs to be done. The code and storage cost is minimal. Phplib isn't just experimental code for the developers to enjoy playing with (although I would guess that you do :-) There are people out here in the trenches using it for customer websites who depend on it for a living. Ciao, -- 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 | | |
From: Giancarlo <gia...@na...> - 2003-01-22 09:01:16
|
Is This is because $sess, in the phplib API, used to have its own $sess->in and $sess->pt, and used to treat these in a particular way, differently as userland properties, and used to make them persistent in its' own way (w/o a $sess->register), In practice, they were not userland session variables, but properties of the session object (as coming from source) that could be overriden in any instance, and stay persistent from that moment on... The $sess->in property is a persistent switch that states wether that stuff has been autoloaded at init time, or not. So that it won't be reloaded on subsequent obj instantiation. In the past we used to have something like eval("\$sess->in=1") in the persistent code, that woud be evaluated on resumption. Now I dunno how to solve this, except using a non-$sess property for it, as register("sess_in") > I like the idea of preserving sess->in instead. page_close is already How can we preserve $sess->in if $sess itself is not made persistent? I don't think we should make $sess persistent, it never was. And that would mean to select just the properties we want to save, with a __sleep() function and defining persistent_slot("in"). Too much change, isn't' it? > required again if you use register_globals off. > > thanks for tracking this down. > > Joe > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Scholarships for Techies! > Can't afford IT training? All 2003 ictp students receive scholarships. > Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. > www.ictp.com/training/sourceforge.asp > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users > |
From: Giancarlo <gia...@na...> - 2003-01-23 17:11:35
|
Is this too semple? untested. maybe one should use $_SESSION instead of $GLOBALS. ## 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(); |
From: Joe S. <joe...@us...> - 2003-01-23 19:38:17
|
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 |
From: Lindsay H. <fmo...@fm...> - 2003-01-23 19:46:02
|
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 | | |
From: Joe S. <jo...@be...> - 2003-01-24 21:51:49
|
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 | | > |
From: Lindsay H. <fmo...@fm...> - 2003-01-23 20:28:12
|
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 | | |
From: Giancarlo <gia...@na...> - 2003-01-24 10:27:30
|
> 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. > |
From: Lindsay H. <fmo...@fm...> - 2003-01-24 19:15:16
|
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 | | |
From: Giancarlo <gia...@na...> - 2003-01-24 22:03:36
|
> 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 |
From: Joe S. <jo...@be...> - 2003-01-24 22:19:04
|
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 > |
From: Giancarlo <gia...@na...> - 2003-01-25 10:21:10
|
> 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; .... |
From: Giancarlo <gia...@na...> - 2003-01-25 10:24:43
|
> > 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 |
From: Giancarlo <gia...@na...> - 2003-01-25 10:43:42
|
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'? |
From: Joe S. <jo...@be...> - 2003-01-24 21:45:42
|
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 | | |
From: Giancarlo <gia...@na...> - 2003-01-24 22:14:06
|
>>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 |
From: Lindsay H. <fmo...@fm...> - 2003-01-24 23:33:45
|
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 | | |