Objects and sessions

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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

    require( "php_includes/class_web_page.php" );

    if ( !$_SESSION["page"] )
        $page = new Web_page();
        $_SESSION["page"] = &$page;
        $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.


Re: Objects and sessions

dmcconkey@yahoo.com wrote:

Quoted text here. Click to load it


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();

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


Re: Objects and sessions

Quoted text here. Click to load it

I suppose I should try to sell you my product... (see my sig) :-)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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/a867.html#http_auth_logout

Quoted text here. Click to load it

Actually, I think this starts to explain question #1.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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

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

Site Timeline