Thread: [Phplib-users] Re: [Phplib-core] Re: cvs snapshot on sf.net
Brought to you by:
nhruby,
richardarcher
Menu
▾
▴
phplib-users
|
From: Maxim D. <max...@bo...> - 2002-09-26 07:50:28
|
Hello Joe, Wednesday, September 25, 2002, 8:33:33 PM, you wrote: >> This could be also done in prepend.php by doing extract($_SESSION); JS> Yes. This would put more conditionals in prepend which I personally don't JS> like. Sorry, I meant page.inc, not prepend.php, which is used to include all the necessary classes. Page.inc itself just for such conditionals. JS> It also moves code that is required for session4.inc to work JS> correctly in this state out of the class. Well ... but that would be much more efficient :) >> in Ssssion::is_registered: >> return session_is_registered($var_name); >> should be >> return (session_is_registered($var_name) || >> isset($_SESSION[$var_name])); >> in Session::unregister: >> $ok = $ok && session_unregister ( trim($var_name) ); >> should be >> $var_name = trim($var_name); >> $ok = $ok && (session_unregister($var_name) || >> unset($_SESSION[$var_name])); JS> What effect should you see with this change? Variables may be registered in both ways, by using $sess->register() or by direct assignment to $_SESSION keys. So, we should mind both ways in is_registered and unregister. I suspect session_register/session_unregister/session_is_registered know nothing about $_SESSION array. $_SESSION and $HTTP_SESSION_VARS (the old way) are different arrays, and not linked to each other. JS> I ask because Gian's patch basically chose the _SESSION route if globals JS> off. He and I found that the session_register, session_unregister, and JS> is_registered all function as before. See his added note to the patch on JS> sf.net. JS> The one anomaly he found is on the same iteration that the session JS> variable is registered, he could use $_SESSION[variablename] to get the JS> variable contents. I have not been able to get this to work ( It could be JS> my test). Yes, I saw the note, but if they changed the behavior once, nothing prevents them from changing things again, e.g. for performance reasons. The documented behavior is that those functions don't work with register_globals=off. >> maybe references to the session variables should be put into $_SESSION >> in Session::register as well, since $HTTP_SESSION_VARS and $_SESSION >> are not the same arrays. That would eliminate freeze in Session. I >> don't like that freeze idea :) JS> In practice this hasn't worked for me. I'd like to get rid of that ugly code in sess->>freeze too. It was just proof-of-concept. If we register variables the both ways in the both session arrays, freeze hs nothing to do in Session4, cause the standard savehandler itself knows where to look for the session variables (though, it needs to be in Session4_Custom) -- 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: Marko K. <M.K...@os...> - 2002-09-26 08:50:07
|
Hi Joe and Maxim, I got Joe's code from the snapshot up and running with 'register_globals=off' eventually. I struggled a lot to get my app back to live, but to the cost of not allowing anymore appended SIDs to my urls with 'session_trans_id=0'. It doesn't hurt much, since it looks like it makes sense to use cookies instead. But, what is strange is that the session4_custom still doesn't seem to work properly, as it is coded now. Though I use a Session_Custom with $sess->module set to 'files' there are no entries created in the mysql db, instead I see the usual php4 /tmp/sess* file appearing... Any idea why this is so? Greetings, Marko |
|
From: Maxim D. <max...@bo...> - 2002-09-26 09:50:31
|
Hello Marko, Thursday, September 26, 2002, 12:49:52 PM, you wrote: MK> But, what is strange is that the session4_custom still doesn't seem to MK> work properly, as it is coded now. Though I use a Session_Custom with $sess->module set to 'files' there are no entries created in the mysql db, MK> instead I see the usual php4 /tmp/sess* file appearing... MK> Any idea why this is so? Because of 'files' in Your $sess->module. Should be 'user' for the custom storage, like db. -- 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: Marko K. <M.K...@os...> - 2002-09-26 12:30:29
|
> Because of 'files' in Your $sess->module. Should be 'user' for the > custom storage, like db. aaaaaaaaaaaaaaaaaaaaaaarghhhhhh, well, of course, I am so stupid... Totally forgot this point. I saw it in the code and I used it this way with 'user' in my old application. But since I took Joe's code as is I certainly didn't change the module=files setting. Now I understand why everything worked just fine with standard php4 sessions and your style... THANKS, Maxim. Now my app works fully with "register_globals=off", php3-, php4- and php4-custom sessions!!!!!!!!!!! I only have to revise most of my scripts concerning all these GET-variables which I still use on my page. Since I don't use default auth I don't seem to have problems anymore. Session work, auth works, user4 works, the only quirck is that oohforms doesn't work without complete restore of all POST parameters. Bye, Marko |
|
From: Dr T. S. <ta...@sa...> - 2002-09-26 12:40:19
|
On Thu, 26 Sep 2002, Marko Kaening wrote: > Session work, auth works, user4 works, the only quirck is that oohforms > doesn't work without complete restore of all POST parameters. From the notes in the PHPlib manual =================================== The following file contains patch for OOHForms to work with register_globals off http://www.sanisoft.com/phplib/oohforms_patch.zip =================================== Cheers Tarique -- ============================================================= PHP Applications for E-Biz: http://www.sanisoft.com Indian PHP User Group: http://groups.yahoo.com/group/in-phpug ============================================================= |
|
From: Joe S. <jo...@be...> - 2002-09-26 17:12:58
|
On Thu, Sep 26, 2002 at 11:49:56AM +0400, Maxim Derkachev wrote: > > Sorry, I meant page.inc, not prepend.php, which is used to include all > the necessary classes. Page.inc itself just for such conditionals. > > JS> It also moves code that is required for session4.inc to work > JS> correctly in this state out of the class. > Well ... but that would be much more efficient :) > Like I said, I'm open. Just using extract would be fine ( outside any function I guess?) > Variables may be registered in both ways, by using $sess->register() > or by direct assignment to $_SESSION keys. So, we should mind both > ways in is_registered and unregister. I suspect > session_register/session_unregister/session_is_registered know nothing > about $_SESSION array. $_SESSION and $HTTP_SESSION_VARS (the old way) > are different arrays, and not linked to each other. > yes, this seems to be the case. > JS> I ask because Gian's patch basically chose the _SESSION route if globals > JS> off. He and I found that the session_register, session_unregister, and > JS> is_registered all function as before. See his added note to the patch on > JS> sf.net. > JS> The one anomaly he found is on the same iteration that the session > JS> variable is registered, he could use $_SESSION[variablename] to get the > JS> variable contents. I have not been able to get this to work ( It could be > JS> my test). > Okay, got it to work. It was my test. Note however that the contents of $_SESSION[variablename] are not kept up to date if register_globals is off. A simple test in pages/index.php3: printf("<h1>Per Session Data: %s</h1>\n", ++$s); add----> printf("<h1>Per Session Data: %s</h1>\n", $_SESSION['s']); > Yes, I saw the note, but if they changed the behavior once, nothing > prevents them from changing things again, e.g. for performance > reasons. The documented behavior is that those functions don't work > with register_globals=off. > totally agree. > > > >> maybe references to the session variables should be put into $_SESSION > >> in Session::register as well, since $HTTP_SESSION_VARS and $_SESSION > >> are not the same arrays. That would eliminate freeze in Session. I > >> don't like that freeze idea :) > > JS> In practice this hasn't worked for me. I'd like to get rid of that ugly > code in sess->>freeze too. It was just proof-of-concept. > Okay, got this to work too with Gian's session4.inc.new with only one small change. So, corresponding patches, etc will be updated accordingly. Any problem moving the require statement for session4.inc out of session4_custom.inc? thanks, Joe > -- > 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: Joe S. <jo...@be...> - 2002-09-26 21:17:06
|
On Thu, Sep 26, 2002 at 12:11:28PM -0500, Joe Stewart wrote: > > > > > > >> maybe references to the session variables should be put into $_SESSION > > >> in Session::register as well, since $HTTP_SESSION_VARS and $_SESSION > > >> are not the same arrays. That would eliminate freeze in Session. I > > >> don't like that freeze idea :) > > > > JS> In practice this hasn't worked for me. I'd like to get rid of that ugly > > code in sess->>freeze too. It was just proof-of-concept. > > > > Okay, got this to work too with Gian's session4.inc.new with only one > small change. > Sorry to follow up my own post, but I was wrong. I can't make this work and I'm not going to spend a lot of time trying. It works as posted with the sess->freeze method. I'm still not understanding that the state would be saved with register_globals off by saving a variable to $_SESSION earlier in the script. > So, corresponding patches, etc will be updated accordingly. > done. Some modifications to the demo files was done too. Joe |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X