tags:

views:

24

answers:

3

The site I'm renovating writes session data to their database using the session_set_save_handler function as follows:

session_set_save_handler (array(&$ses_class, '_open'), 
                          array(&$ses_class, '_close'), 
                          array(&$ses_class, '_read'), 
                          array(&$ses_class, '_write'), 
                          array(&$ses_class, '_destroy'), 
                          array(&$ses_class, '_gc'));

I have the _open, _close, etc. functions log any calls they receive to the error_log file but upon opening I only see calls to _write and _close. Why would these be the only functions being called?

Also, depending on the page I'm on the _write function can or cannot write to the database, returning an 'Access denied...(using password: NO)' mysql_error.

I'm at a loss. Any good resources I should look at?

+1  A: 

You're definitely calling session_start() after session_set_save_handler?

'Access denied...(using password: NO)' mysql_error.

That usually indicates that the the database hasn't been connected to, so PHP is attempting to connect with the default username and no password, which 99.999% of the time doesn't work. E.g. mysql_query() is being called before mysql_connect()

Sounds like problems with the ordering of the code.

Pete
As to the first question, yes. With regards to the second, a persistent connection is established using mysql_pconnect in the _open function. I'm not sure the _open function is ever called, as it never shows up in my error_log. Is this always called? Why isn't it logging itself?
S McKinley
Can you post the session class code? Also have a look at http://shiflett.org/articles/storing-sessions-in-a-database
Pete
Thanks Pete. I had a look at that article and it definitely helped. I also stored the database resource associated with the session object so that I could explicitly refer to it in the object methods. This resolved the issue of not being able to write to the database. Apparently subsequent database connections were clobbering my original connection.
S McKinley
A: 

PHP 5.1 had a bug where objects were destroyed before the session was closed. My solution was to create a destructor function for my DB object that explicitly closed the session.

The other problem is that you might have code starting up the session before the database connection is initialized. That requires carefully tracing through your includes looking for global code unexpectedly calling $_SESSION. This will also play hop with your session_set_save_handler() call. I had that problem in a previous job. The only solution was to re-order how things initialized so they didn't happen in the wrong order.

staticsan
I'll check that out, staticsan. Thanks for the tip.
S McKinley
A: 

My question was two-part and this answer corresponds to the second part, the issue of not being able to write to the database.

The session object the site I'm working on uses did not store the database resource and so database connections made downstream in the code were clobbering the session's connection. I created an object variable to store the database resource and explicitly referred to it in all session queries, i.e.

$result = mysql_query($query)

became

$result = mysql_query($query, $this -> db);

and I'm now able to write to the database just fine.

S McKinley