new session_register / serialize

pinkbike

For some reason I thought all this time that the serialize() functions can store multiple variable names and their values. I guess I was worng.

What I'm trying to do is do a custom session_register function. Basically everytime i call session_register($x) that variable name and valuse is added to a serialized string from which I can later extract the variable name value pairs.

How would you do this? Is it as simple as a 2 dimensional array which just gets serialized at the end? Any other ideas.
How does the php session_register() function do this currently?

Thanks a bunch.

Anon

What's the problem you're having? Once you session_register('x') (note: not $x, but "x") PHP will handle all the serialisation/deserialisation itself, and you can just go ahead and work with $x; PHP will reserialise its value on script's end.

If you want to use the sessioned variables in an array, its name is $HTTP_SESSION_VARS and/or (in the most recent versions of PHP) $_SESSION.

If you're that curious, the serialised data is typically stored in a file in /tmp named for the session ID.

pinkbike

You are right I was thinking you pass $x but actually you just pass the name x.

Anyway I'm just trying to write my own session functions. Primarely to use a database instead of the file based sessions that are available through php. I know that I can add handlers to php to use a different back end but I guess I want to understand what is actually going on under the hood so I'm diving in a little deeper.

This is what I was looking for. Just a basic way to add variable/value pair and create a serialized string which can be stored in a database, and then extracting the variable/value pairs and then making the variables available as they were before.
Basically just what the php functions do but I guess at the first principle level.

Is there an advantage to using the php session_register() functions as opposed to writing your own?

function bp_session_register($var)
{

//globalize the passed in variable and the session data array.
global $sess_data,$$var;

//add,overwrite variable name / value pair
$sess_data[$var]=$$var;

//normally we would write to database
//bp_session_write(serialize($sess_data));

}

function bp_session_start($sess)
{
//normally we would read the serilized session data from the database
//$sess_data=bp_session_read(serialize($sess_data));

global $sess_data;

while (list($var,$value) = each($sess_data))
{
global $$var;
$$var=$value;
}

}

$name="radek";
bp_session_register("name");

$id=23;
bp_session_register("id");
print("<br>TEST2: NAME=$name, ID=$id");

unset($name);
unset($id);
//this should have no value as variables are unset
print("<br>TEST3: NAME=$name, ID=$id");

//this should reinitialize the variables
bp_session_start(3);

print("<br>TEST4: NAME=$name, ID=$id");

Anon

Advantages? Convenience, mainly - before PHP4 sessioning had to be roll-your own (or use someone else's library, like PHPLib). And sessioning can have a lot of snags for the unwary or inexperienced. You might want to glance through the code for PHPLib if you're looking for inspiration in your own project.

For roll-your-own you have finer control over what happens when, and you can specify additional tasks to be carried out in the event of things like session destruction and creation; for high-load sites a database-driven sessioning system is probably faster than the typical file-based one. On the other hand, of course, you have to be up to the task :-)

On the gripping hand, if you don't need just detail, PHP's builtin sessioning is Good Enough (and saves code if you're lazy like me).

pinkbike

I've recently added PHP session handling (file based) to my hobby site and I can see the difference when pages have the session_start and ones that dont.
I like to speed things up as much as I can. The site gets a modest 1 million hits / DAY and as it grows I want to make sure things are streamlined.
The site is www.pinkbike.com (Dont worry, it's not porn 🙂 )
CIAO

Anon

The additional lag would be because the server has to query the browser for its session ID cookie before continuing with the script. This would be the case even if you were to roll your own session handlers, unless they avoided the cookie route completely.

The only cookie-free method I can think of that's safe enough to employ to identify browsers across requests with reasonable realiability is to attach a session ID to each URL. Among the problems here is that every page on your site will have to be "sessioned" in this way, to prevent the ID falling off when the visitor goes to a non-sessioned page.