[phplib] Re: Problem with newly commited user4.inc From: Max A. Derkachev (kot <email protected>)
Date: 01/05/01

Hello Marko,

Friday, January 05, 2001, 2:21:42 PM, you wrote:

MK> Right now I noticed that session/user data is stored in php4 manner and
MK> not the way it was before in phplib3 (I mean as clear php code). In
MK> principle this is okay, I think. But at least for me it causes a little
MK> problem now: I cannot simply use the same tables if I switch between old
MK> phplib3 or Brian's phplib4-extension and your approach. I this is a
MK> drawback of the simplyfication by leaving the data in php4 style. but
MK> okay, if you look at speed it's better certainly.

I use the same tables as earlier, and it works for me.
Of course, the format of the serialized data has been changed (now
it's in format, that session_encode() provides, it could be a PHP
serialize() format or wddx format), and it is incompatible with old
session3 format. You can not read session data,
serialized by session3 class, using session4 class. But it's encoded by
base64_encode() or addslashes() (it depends on $encoding_method in
CT_Sql), and this string value can always be stored in a val TEXT field of
active_sessions table, or another character field, depending of the
CT_* class and database you're using. So, you can use old tables, but,
of course, can not use old values.

MK> I found the definition
MK> var $vars_array = 'PHPLIB_USER_VARS';
MK> in the user4.inc.
MK> But I didn't see a connection of this variable to anything else in the
MK> whole phplib. Maybe that's the problem? The error messages up there
MK> actually try to access $vars_array and maybe that's the cause of
MK> everything?
Let me explain at first how all this is intended to work (after all
bugs will be eliminated :)).
$vars_array contains the name of a global associative array which keys
are names of registered variables and values are references to those
variables. The variables you're registering should be global. I've
borrowed this approach from PHP4 session engine, $HTTP_SESSION_VARS
array namely.
When you register something in User, a global array, named
$PHPLIB_USER_VARS by default, should appear. The User class references
it as $GLOBALS[$this->vars_array]. No other part of phplib uses this
array - its purpose is to contain references to registered user
variables, it is serialized by serialize() at page_close() call and
this serialized value is saved in the database.
User::register_globals is a cousin of the PHP's register_globals
directive. If it is set to true, all registered user vars should
appear in a global namespace, if it is false, all the registered user
variables will appear only in $PHPLIB_USER_VARS, similarly to the PHP4
session engine, when all the session vars are in $HTTP_SESSION_VARS,
but not in global namespace, when php.ini's register_globals is set to
'off'.
As you can see, the class is intended (:)) to work similarly to the PHP4
session engine.
Anyway, the User class should be rewritten to use along it with PHP4
sessions. The problem is that the old User inherits Session. With PHP4
sessions, it does not make sense - you'll either screw up User or
Session (maybe both), cause Session uses native PHP4 mechanism, which
was written to handle sessions, nothing else (you can not have two
real sessions simultaneously, but the old scheme indeed do something like
that).

MK> Well I just started with my active_sessions table from zero (emptyness I
MK> mean) and the only string in the User value is the following line:
MK> -------------------------
MK> Exp_User:b:0;
MK> -------------------------
MK> that's all. Nothing else was actually saved. Well, this is certainly
MK> caused by the problems occuring everytime you call the user4_custom.inc.

Thanks to you again for bug report. For now I'd recommend not to use
user4.inc in a production environment, but, of course, I'd be
appreciated if you test it. To use the old User class, you should
rename the old session class to something like Session3 to prevent
conflicts (e.g. "class Session3" in the session3.inc, so you can
include it along with new session class, and change in the User class
definition "Session" to "Session3" :
Class User extends Session3 {
....
So you'll get new session engine and be able to use you User settings
with old stable User class.
I'll hack user4.inc a bit and make fixes ASAP.

P.S. just found in NEWS in 4.0.4 source tree:
- Added support for serializing references (Stas)
That means that user4.inc won't work with PHP < 4.0.4

MK> Hope to hear from you some time. Uspehi! ;)

Bud' zdorov! :) 

-- 
Best regards,
Max A. Derkachev mailto:kot <email protected>
Symbol-Plus Publishing Ltd.
phone: +7 (812) 324-53-53
http://www.Books.Ru -- All Books of Russia
 

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>