Objects and sessions

[dmcconkey@yahoo.com]

Hi folks,

I have two PHP questions concerning objects stored in sessions.

I'm developing an intranet for a client to be run in a Redhat 8/Apapche
2/PHP 4/MySQL environment. All pages are password protected and I get
to choose how to authenticate and layer permissions.

My first thought to this affect is to use the User table of the mysql
database to maintain site users rather than create a redundant users
table in some other database. MySQL does a great job with permissions,
and since I have root access, it seemed the natural course of action.

The user logs in by supplying name and password via an HTML form and
the authentication functions attempt a mysql_connect() with the
supplied arguments. If mysql_connect() returns greater than false, the
user clears.

Since I couldn't store the mysql_connect() in $_SESSION, I created an
object to store all of my "state" values, and it seems to work. (Though
I'm not certain why you can't store a db connection directly into
session vars, but can when they're embedded in an object.)

My (current) code for instantiating the object and storing it is as
follows:

<?php
require( "php_includ es/class_web_page. php" );
session_start() ;

if ( !$_SESSION["page"] )
{
$page = new Web_page();
$_SESSION["page"] = &$page;
}
else
{
$page = $_SESSION["page"];
}
...blah, blah, blah...

Question 1: I'm not sure that I'm ever killing this object and freeing
up its memory. When the session ends, will the object die with it?
Being a non-public application with low traffic, a small memory leak
won't show up for a long while, but I don't want to find out in a year
or so that I have to re-engineer the whole thing due to my current lack
of foresight.

Question 2: My first thought was to store a reference to the object
(&$page) in $_SESSION. (Coming from C, I figured I was storing a memory
address and that the interpreter automatically dereferenced it.) My
thinking was that storing the memory address was lighter on the
$_SESSION size. Reading up on PHP, I find that no, referencing in PHP
essentially duplicates the variable. (I'm not really passing by
reference, am I?) Am I now making a doubly wide memory allocation by
using my reference? Combine that with question 1, am I now creating a
memory leak twice as large?

Generally speaking, I'm pretty sure that I'm going about this with my
head up my a$$? If a more elegant/efficient solution should be taken,
I'd appreciate the criticism.

Thanks,
-Dan

[Colin McKinnon]

Re: Objects and sessions

dmcconkey@yahoo .com wrote:
[color=blue]
> Hi folks,
>
> I have two PHP questions concerning objects stored in sessions.
>
> I'm developing an intranet for a client to be run in a Redhat 8/Apapche
> 2/PHP 4/MySQL environment. All pages are password protected and I get
> to choose how to authenticate and layer permissions.
>
> My first thought to this affect is to use the User table of the mysql
> database to maintain site users rather than create a redundant users
> table in some other database. MySQL does a great job with permissions,
> and since I have root access, it seemed the natural course of action.
>
> The user logs in by supplying name and password via an HTML form and
> the authentication functions attempt a mysql_connect() with the
> supplied arguments. If mysql_connect() returns greater than false, the
> user clears.
>
> Since I couldn't store the mysql_connect() in $_SESSION, I created an
> object to store all of my "state" values, and it seems to work. (Though
> I'm not certain why you can't store a db connection directly into
> session vars, but can when they're embedded in an object.)
>
> My (current) code for instantiating the object and storing it is as
> follows:
>
> <?php
> require( "php_includ es/class_web_page. php" );
> session_start() ;
>
> if ( !$_SESSION["page"] )
> {
> $page = new Web_page();
> $_SESSION["page"] = &$page;
> }
> else
> {
> $page = $_SESSION["page"];
> }
> ...blah, blah, blah...
>
> Question 1: I'm not sure that I'm ever killing this object and freeing
> up its memory. When the session ends, will the object die with it?[/color]

Yes.
[color=blue]
>
> Question 2: My first thought was to store a reference to the object
> (&$page) in $_SESSION. (Coming from C, I figured I was storing a memory
> address and that the interpreter automatically dereferenced it.) My
> thinking was that storing the memory address was lighter on the
> $_SESSION size. Reading up on PHP, I find that no, referencing in PHP
> essentially duplicates the variable. (I'm not really passing by[/color]

Not really, but when you store an object with references to other objects,
you store the other objects too - so...

class container()
{
var contained;
function set_contained(& $new_obj)
{
$this->contained=& $newobj;
}
}

$test=new object();
$subject=new container();
$subject->set_contained( $test);
....
$replace=null;
$subject->set_contained( $replace);

....or you could use the __sleep method to do something similar.
HTH

C.

[nospam@geniegate.com]

Re: Objects and sessions

In: <1110375949.833 440.42580@o13g2 000cwo.googlegr oups.com>, dmcconkey@yahoo .com wrote:[color=blue]
>I'm developing an intranet for a client to be run in a Redhat 8/Apapche
>2/PHP 4/MySQL environment. All pages are password protected and I get
>to choose how to authenticate and layer permissions.[/color]

I suppose I should try to sell you my product... (see my sig) :-)
[color=blue]
>My first thought to this affect is to use the User table of the mysql
>database to maintain site users rather than create a redundant users
>table in some other database. MySQL does a great job with permissions,
>and since I have root access, it seemed the natural course of action.[/color]

This seems like a good idea, but you have to ask youself if you want
each user to have access to database stuff? I mean, are you placing things
in those tables that don't belong there? If not, then it's probably
not a bad idea. Personally, I'd have a bad feeling about it.
[color=blue]
>The user logs in by supplying name and password via an HTML form and
>the authentication functions attempt a mysql_connect() with the
>supplied arguments. If mysql_connect() returns greater than false, the
>user clears.[/color]

Careful about invalid logins -vs- database connection problems.

Another potential "gotcha" is using other stuff with it, HTTP based
authentication may be a good route for an intranet because it works
with PHP applications that have no access control as well as Perl (shell
or even static HTML) This isn't an insurmountable deal, with apache and
mod_rewrite, though it is an extra step.

Downside of HTTP based is that there isn't a good way to log out.

See: http://www.geniegate.com/manual/v01/...tp_auth_logout
[color=blue]
>Since I couldn't store the mysql_connect() in $_SESSION, I created an
>object to store all of my "state" values, and it seems to work. (Though
>I'm not certain why you can't store a db connection directly into
>session vars, but can when they're embedded in an object.)[/color]

Actually, I think this starts to explain question #1.
[color=blue]
>Question 1: I'm not sure that I'm ever killing this object and freeing
>up its memory. When the session ends, will the object die with it?[/color]

Session data is typically serialized and written to the filesystem
or in some cases, a database BLOB. I suppose it could be stored in shared
memory or something, but I've never seen that done. (Except maybe a
filesystem created on a block RAM device or something)

The session "ends" when the file is erased, PHP has some built in stuff
for removing session files, but you can actually remove them by
simply deleting the sess_ files from /tmp or /var/tmp or wherever
your PHP is putting them.
[color=blue]
>Question 2: My first thought was to store a reference to the object
>(&$page) in $_SESSION. (Coming from C, I figured I was storing a memory
>address and that the interpreter automatically dereferenced it.) My
>thinking was that storing the memory address was lighter on the
>$_SESSION size. Reading up on PHP, I find that no, referencing in PHP
>essentially duplicates the variable. (I'm not really passing by
>reference, am I?) Am I now making a doubly wide memory allocation by
>using my reference? Combine that with question 1, am I now creating a
>memory leak twice as large?[/color]

When an object is "alive", it is only valid during the page request,
after that it's frozen.

Try requiring a PHP class, creating an object and then storing it in a session.
After that, try loading the page (or another page) that uses the object from a
session BEFORE requiring the PHP class the object belongs to. This should prove
it's not been stored in memory as an object, (and also explain why you can't
store database connections in a session)

You'll get errors because the objects class isn't available. This is because
PHP is taking the session data (Have a look at one of it's session files) and
deserializing it, no associated class? Hmm.. panic time. Guess you could say
session objects just 'have no class' (yuk, yuk). (well, actually they sort
of do, in so far as they know WHAT class to populate, they just don't know
WHERE that class is)
[color=blue]
>Generally speaking, I'm pretty sure that I'm going about this with my
>head up my a$$? If a more elegant/efficient solution should be taken,
>I'd appreciate the criticism.[/color]

Hopefully I'm not being critical. :-) Sessions data is rather confusing.

Jamie
--
http://www.geniegate.com Custom web programming
guhzo_42@lnubb. pbz (rot13) User Management Solutions