[horde] horde 3.0.5, postgresql session handler fails
chuck at horde.org
Sat Oct 8 17:52:08 PDT 2005
Quoting Chris Stromsoe <cbs+horde at cts.ucla.edu>:
> After passing in authentication credentials, read() gets called with
> a session
> id as above, starts a transaction, and selects on the sesion id FOR UPDATE to
> lock it. In login.php on line 71 Horde::getCleanSession() is called,
> generating a new session id. write() gets called with the new session id,
> which does an UPDATE which fails because there is no row in the table
> with the
> new session id.
If there's no new read() call there, that's probably a bug in PHP -
getCleanSession() triggers a complete re-set of the session handler.
What PHP version do you have?
> Compounding the problem, the failure is not detected. From
> /* Build the SQL query. */
> $query = sprintf('UPDATE %s SET session_lastmodified = %s,
> session_data= %s WHERE session_id = %s; COMMIT;',
> /* Log the query at a DEBUG log level. */
> Horde::logMessage(sprintf('SQL Query by
> query = "%s"', $query),
> __FILE__, __LINE__, PEAR_LOG_DEBUG);
> $result = @pg_query($this->_db, $query);
> $success = (pg_affected_rows($result) == 0);
> Because the update query includes the COMMIT, I'm pretty sure that
> pg_affected_rows() will return the result of the COMMIT not the result of the
> UPDATE, which means that the test for pg_affected_rows() == 0 will always be
> true. Testing to see if the UPDATE was succesful should probably be testing
> for pg_affected_rows() == 1.
If you can test this and post a patch on bugs.horde.org it'd be greatly
"But she goes not abroad in search of monsters to destroy." - John
More information about the horde