Thread: [Phplib-users] phplib-php4 object resumption differences
Brought to you by:
nhruby,
richardarcher
From: Giancarlo <gia...@na...> - 2002-09-26 22:12:15
|
Now I realize a basic difference among the two, and really appreciate sound phplib ideas like pt, classname, persistent slots etc. Let's see the auth object as an example, which seems I never know enough. In phplib It has 2 fashions: default_auth and normal. When phplib sess stores the object, it stores text, wich is in fact code that is evalued at runtime. This text says: generate a new class by that class name, and instantiate these varalues and properties. It does not reinsantiate all properties, but only those that were marked as persistent_slots. In practice it generates a new object with the name and definition available at runtime, and merges into theat the persistent_slots found. php4, on the other hand, stores full object and reinstiantiates them automatically at startup, with all the values like they were. At runtime these values are reloaded, ALL the values are taken back. It is not a merge. I think this is a major difference With persistent slot you don't leave unconscoiusly, unaccounted or unwanted data around. Wheren't we of phplib, those who leave the id and nothing more, for greater security? I read that in every example article about 'good session mangmnt rules': leave a minimud md5 ID, and hook most values in the db...So note that with php4 everything is written in the sess_ file, plaintext, passwd etc, if you don't provide tu unset everything not needd before page_close. Which is much the same as a reversing persistent_slot, but uglier ciao bonanotte Gian |
From: Maxim D. <max...@bo...> - 2002-09-27 06:53:20
|
Hello Giancarlo, Friday, September 27, 2002, 2:07:52 AM, you wrote: G> php4, on the other hand, stores full object and reinstiantiates them G> automatically at startup, with all the values like they were. At runtime G> these values are reloaded, ALL the values are taken back. It is not a merge. G> I think this is a major difference G> With persistent slot you don't leave unconscoiusly, unaccounted or unwanted G> data around. ....................................... <skipped> Did you read my yesterday's message concerning __sleep & __wakeup? -- 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-27 08:42:49
|
> G> With persistent slot you don't leave unconscoiusly, unaccounted or unwanted > G> data around. > ....................................... > <skipped> > Did you read my yesterday's message concerning __sleep & __wakeup? > Well, I noticed that the custom sessions (if you're not using extensively many session variables, which I don't do since everything is stored via your user4) slows my app only by 3% down in comparison to pure php4 sessions. So, for security one could simply use the session4_custom.inc instead. Marko |
From: Maxim D. <max...@bo...> - 2002-09-27 09:11:21
|
Hello Marko, The problem described by Giancarlo does not apply to the PHP's serialize behavior, not Session4_Custom in particular. If you want to make serialize not to save all the class variables, you should define __sleep & __wakeup in serialized classes. This also apply to the classes saved by User4, since it also serializes objects using PHP serialize(). Friday, September 27, 2002, 12:42:37 PM, you wrote: >> G> With persistent slot you don't leave unconscoiusly, unaccounted or unwanted >> G> data around. >> ....................................... >> <skipped> >> Did you read my yesterday's message concerning __sleep & __wakeup? >> MK> Well, I noticed that the custom sessions (if you're not using extensively MK> many session variables, which I don't do since everything is stored via MK> your user4) slows my app only by 3% down in comparison to pure php4 MK> sessions. So, for security one could simply use the session4_custom.inc MK> instead. -- 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: Giancarlo <gia...@na...> - 2002-09-27 11:07:12
|
Il 11:10, venerd=EC 27 settembre 2002, Maxim Derkachev ha scritto: > Hello Marko, > > The problem described by Giancarlo does not apply to the PHP's > serialize behavior, not Session4_Custom in particular. If you want to > make serialize not to save all the class variables, you should define > __sleep & __wakeup in serialized classes. This also apply to the > classes saved by User4, since it also serializes objects using PHP > serialize(). Ok. Now look at how the auth object is serialized. Suppose you have an auth object created by the Example_auth class. the on= ly=20 persistent slot is designed to be the $auth->auth array. Not even classna= me. You make persisten a session that has an auth class with classname=20 Example_auth and nobody=3Dfalse (no default_auth). You then open a page that HAS default_auth. It resumes from persistance a= =20 completely different auth object.=20 IF (and only if) here was not one persistent, it creates one, with classn= ame=20 Example_auth and, most important, var $nobody=3Dtrue. It will obviously i= nherit=20 the whole $auth->auth array, but these properties, that were meant to sta= y=20 OUT of pertsistance, are not, and thus not respected. So really a bug it is, for me Gian |