phplib-users Mailing List for PHPLIB (Page 23)
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users — A list for users of phplib to talk / discuss phplib
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(106) |
Sep
(99) |
Oct
(44) |
Nov
(97) |
Dec
(60) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(56) |
Feb
(81) |
Mar
(134) |
Apr
(69) |
May
(106) |
Jun
(122) |
Jul
(98) |
Aug
(52) |
Sep
(184) |
Oct
(219) |
Nov
(102) |
Dec
(106) |
| 2003 |
Jan
(88) |
Feb
(37) |
Mar
(46) |
Apr
(51) |
May
(30) |
Jun
(17) |
Jul
(45) |
Aug
(19) |
Sep
(5) |
Oct
(4) |
Nov
(12) |
Dec
(7) |
| 2004 |
Jan
(11) |
Feb
(7) |
Mar
|
Apr
(15) |
May
(17) |
Jun
(13) |
Jul
(5) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(21) |
Dec
(13) |
| 2005 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
(7) |
May
|
Jun
(11) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
|
| 2006 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
(9) |
Nov
|
Dec
(5) |
| 2007 |
Jan
(15) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(12) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(19) |
Sep
(2) |
Oct
|
Nov
|
Dec
(6) |
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
|
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-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: 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-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: 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: 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 05:51:19
|
Attached is a better patch for session4.inc which preserves $sess->in across page accesses. This is obviously friendlier to the published API. All the work is done in start() and freeze(). Because $sess->in is functional, no changes are required to page4.inc. -- 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. <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: 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-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: 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. <fmo...@fm...> - 2003-01-21 01:23:32
|
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: Lindsay H. <fmo...@fm...> - 2003-01-20 03:40:16
|
I've been able to reproduce this on a non-production system so I can poke at the problem at my convenience. I've determined that it's apparently _not_ thread related. If no one has a solution on this, I'll try to find the time to track it down in phplib - when I get a round tuit. Anyone got any spare round tuits? Thus spake Lindsay Haisley on Sat, Jan 18, 2003 at 02:34:59PM CST > I'm having a weird problem here which appears to be related to phplib > database (not native php4) session management, and is dependent on the > version of apache I'm running but _not_ the version of php4. > > I have a lot of pages here which do session management using mysql > databases, phplib and php4. Everything works as expected with the following > software combination: > > apache: 1.3.26 > php: 4.3.0 > phplib: 7.4-pre2 > > If I switch to apache 2.0.43, using php4 as a dso compiled for it (same php > version, almost the same configure options, same php.ini file, same phplib > files), phplib will no longer issue cookies to track sessions. > > Cookies are working. I can set a cookie using <meta http-equiv ...>, or I > can set an arbitrary cookie using php with setcookie(), and I can read the > cookies on the server side with php using the $_COOKIE global array, but I > can't get any cookie-based session tracking to the MySQL databases set up > for this purpose. Other features, including other database access and php4 > functionality, seem to be working OK. > > I'm using mozilla to test, and have it set to ask permission before > accepting a cookie, and when the server is apache 1.3.26 I always get the > usual cookie question, but when the server is apache 2.0.43 I get no cookie > notice, and phplib apparently falls back on GET variables, and since I have > register_globals off, and don't necessarily accept a GET session id, I end > up with lost sessions. > > The only things changed are the version of apache and the specific php > module used, which was compiled separately for each apache version. > Otherwise, everything is the same. I'm using different httpd.conf files, of > course, but mod_usertrack is in both of them and as I said, cookies are > working, just not phplib session management cookies. > > Has anyone else hit this, and found a solution? Is this perhaps a thread > support problem? -- 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-18 20:36:01
|
I'm having a weird problem here which appears to be related to phplib database (not native php4) session management, and is dependent on the version of apache I'm running but _not_ the version of php4. I have a lot of pages here which do session management using mysql databases, phplib and php4. Everything works as expected with the following software combination: apache: 1.3.26 php: 4.3.0 phplib: 7.4-pre2 If I switch to apache 2.0.43, using php4 as a dso compiled for it (same php version, almost the same configure options, same php.ini file, same phplib files), phplib will no longer issue cookies to track sessions. Cookies are working. I can set a cookie using <meta http-equiv ...>, or I can set an arbitrary cookie using php with setcookie(), and I can read the cookies on the server side with php using the $_COOKIE global array, but I can't get any cookie-based session tracking to the MySQL databases set up for this purpose. Other features, including other database access and php4 functionality, seem to be working OK. I'm using mozilla to test, and have it set to ask permission before accepting a cookie, and when the server is apache 1.3.26 I always get the usual cookie question, but when the server is apache 2.0.43 I get no cookie notice, and phplib apparently falls back on GET variables, and since I have register_globals off, and don't necessarily accept a GET session id, I end up with lost sessions. The only things changed are the version of apache and the specific php module used, which was compiled separately for each apache version. Otherwise, everything is the same. I'm using different httpd.conf files, of course, but mod_usertrack is in both of them and as I said, cookies are working, just not phplib session management cookies. Has anyone else hit this, and found a solution? Is this perhaps a thread support problem? -- 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-18 20:03:04
|
Thus spake Chris Johnson on Fri, Jan 17, 2003 at 03:30:03PM CST > On Thu, Jan 16, 2003 at 10:52:13AM -0600, Lindsay Haisley wrote: > > > Thus spake Joe Stewart on Thu, Jan 16, 2003 at 06:24:02AM CST > > > phplib 7.4-pre2 has been released which has php4 session support. > > > I noticed that, which is why I asked. The comment in session4.inc says, > > however: > > > > * WARNING: code is untested! > > * > > > > Which leads me to conclude that the code may not yet be ready for a > > production environment. > > > Lindsay Haisley | "Everything works | PGP public key > > Maybe the comments in the code would be slightly more useful if they said > "Warning: code was only tested by the developer at the time this comment > was written." Which is to say, given the nature of contributions to this > open source project, and the limited amount of formal organization, PHPLIB > is really only tested by its users, first by the early adopters, and then > by the rest, I guess. I'm cautious by nature on this, since if things break, my phone rings with upset customers asking why. I tend to run a good deal closer to the edge on my personal stuff, and make sure everything that I have deployed on customer sites is solid before I move code and server technology to them. My guess is that the developer's comment is a bit out of date, and a bunch of people have banged on it since the comment was inserted. -- 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: Chris J. <ch...@ch...> - 2003-01-17 21:30:09
|
On Thu, Jan 16, 2003 at 10:52:13AM -0600, Lindsay Haisley wrote:
> Thus spake Joe Stewart on Thu, Jan 16, 2003 at 06:24:02AM CST
> > phplib 7.4-pre2 has been released which has php4 session support.
> I noticed that, which is why I asked. The comment in session4.inc says,
> however:
>
> * WARNING: code is untested!
> *
>
> Which leads me to conclude that the code may not yet be ready for a
> production environment.
> Lindsay Haisley | "Everything works | PGP public key
Maybe the comments in the code would be slightly more useful if they said
"Warning: code was only tested by the developer at the time this comment
was written." Which is to say, given the nature of contributions to this
open source project, and the limited amount of formal organization, PHPLIB
is really only tested by its users, first by the early adopters, and then
by the rest, I guess.
None of the code in the beta releases or actual "final" releases (when we
finally get there) will actually be completely untested. But it is the
case that some gets more testing than others, and that we do not (yet?)
have a nice set of regression tests. That would be very nice to have
should anyone feel like creating or donating such a thing.
--
..chris
|
|
From: Chris J. <ch...@ch...> - 2003-01-17 21:25:45
|
On Wed, Jan 15, 2003 at 12:02:18PM -0600, Fred Yankowski wrote: > Since this thread has been discussing strict separation of HTML and > PHP code using phpLib templates, I'd like to point to a short how-to > on one way to accomplish that via current phpLib templates: > > http://ontosys.com/phplib/examples.php Hey Fred, long time no see. Thanks for dropping in and providing a useful bit of tutorial. -- ..chris |
|
From: Kristian K. <kr...@ko...> - 2003-01-17 10:07:49
|
On Fri, Jan 17, 2003 at 09:11:54AM +0100, Marko Kaening wrote: > > What's the situation with the phplib CVS repository? I can't get to it from > > either the web interface or from my CVS directory which used to work. > I had the same problem! Since the pre2 is out I am unable to access the > anonymous cvs repository with an empty password! There is an upcoming anon exploit in CVS. SF got advance warning and closed all CVS on their site until the crisis is over. Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG |
|
From: Marko K. <M.K...@os...> - 2003-01-17 08:14:04
|
> What's the situation with the phplib CVS repository? I can't get to it from > either the web interface or from my CVS directory which used to work. I had the same problem! Since the pre2 is out I am unable to access the anonymous cvs repository with an empty password! Marko |
|
From: Lindsay H. <fm...@fm...> - 2003-01-16 16:53:16
|
Thus spake Joe Stewart on Thu, Jan 16, 2003 at 06:24:02AM CST > On Wed, Jan 15, 2003 at 09:59:11PM -0600, Lindsay Haisley wrote: > > What is the current status of php4 session management support in phplib? > > The last time I checked (some months ago) this was still a ways down the > > road, and I note that some of the files such as session4.inc are noted as > > "untested", although this, like much in the documentation, may be out of > > date. > > > > phplib 7.4-pre2 has been released which has php4 session support. I noticed that, which is why I asked. The comment in session4.inc says, however: * WARNING: code is untested! * Which leads me to conclude that the code may not yet be ready for a production environment. Some of my hosting customers depend on phplib session management for proper functioning of their websites. One person on this list replied to me saying that he was using phplib with php4 session management successfully on a production site, but I do take warnings such as the above pretty seriously when it comes to deploying software for my customers. Assuming that this code is production ready, what modifications, if any, are required on existing pages using php database session management to convert them to using native php4 session management under phplib? I know, for instance, that page_close() isn't required if one is using php4 session management, but I would hope that I wouldn't have to make sure that all my customer sites with page_close() in one or more of their pages wouldn't require that a null function be defined somewhere for them so as to avoid generating an error. -- 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-16 12:18:48
|
On Wed, Jan 15, 2003 at 09:59:11PM -0600, Lindsay Haisley wrote: > What is the current status of php4 session management support in phplib? > The last time I checked (some months ago) this was still a ways down the > road, and I note that some of the files such as session4.inc are noted as > "untested", although this, like much in the documentation, may be out of > date. > phplib 7.4-pre2 has been released which has php4 session support. http://sourceforge.net/project/showfiles.php?group_id=31885&release_id=133677https://sourceforge.net/project/showfiles.php?group_id=31885&release_id=133677 From the release notes: ---------------------------------------------------------------------------- phplib-7.4-pre2 ---------------------------------------------------------------------------- Some features and improvements include: php4 session support ( prepend.php) register_globals can be off for most classes To use phplib storage with php4 sessions use the session4_custom class extension. 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-16 05:03:56
|
Is it upward compatible with applications and pages developed using phplib sessions stored in a database? I have a bunch of customer sites which depend heavily on php and phplib and I don't want to break anything for them. Thus spake Dr Tarique Sani on Wed, Jan 15, 2003 at 10:40:43PM CST > On Wed, 15 Jan 2003, Lindsay Haisley wrote: > > > What is the current status of php4 session management support in phplib? > > The last time I checked (some months ago) this was still a ways down the > > road, and I note that some of the files such as session4.inc are noted as > > "untested", although this, like much in the documentation, may be out of > > date. > > Try http://phplib.sourceforge.net/snapshots/ has PHP 4 sessions with > register_globals = off and several other enhancements > > I am already using this on one of my commercial project > > Tarique > > -- > =================================================================== > PHP Applications for E-Biz: http://www.sanisoft.com -o) > /\\ > Indian PHP User Group: http://groups.yahoo.com/group/in-phpug _\_v > =================================================================== > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: A Thawte Code Signing Certificate > is essential in establishing user confidence by providing assurance of > authenticity and code integrity. Download our Free Code Signing guide: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en > _______________________________________________ > Phplib-users mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phplib-users -- 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: Dr T. S. <ta...@sa...> - 2003-01-16 04:36:19
|
On Wed, 15 Jan 2003, Lindsay Haisley wrote: > What is the current status of php4 session management support in phplib? > The last time I checked (some months ago) this was still a ways down the > road, and I note that some of the files such as session4.inc are noted as > "untested", although this, like much in the documentation, may be out of > date. Try http://phplib.sourceforge.net/snapshots/ has PHP 4 sessions with register_globals = off and several other enhancements I am already using this on one of my commercial project Tarique -- =================================================================== PHP Applications for E-Biz: http://www.sanisoft.com -o) /\\ Indian PHP User Group: http://groups.yahoo.com/group/in-phpug _\_v =================================================================== |
|
From: Lindsay H. <fmo...@fm...> - 2003-01-16 04:00:13
|
What is the current status of php4 session management support in phplib? The last time I checked (some months ago) this was still a ways down the road, and I note that some of the files such as session4.inc are noted as "untested", although this, like much in the documentation, may be out of date. -- 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-16 02:59:13
|
What's the situation with the phplib CVS repository? I can't get to it from either the web interface or from my CVS directory which used to 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 | | |
17 messages has been excluded from this view by a project administrator.
