[horde] horde 3.0.5, postgresql session handler fails

[Chris Stromsoe]

On Sun, 9 Oct 2005, Chris Stromsoe wrote:

> Anyway, the patch is attached to bug #2749.  It also includes some 
> whitespace cleanup to make lines not wrap on an 80-column terminal, and 
> removes some bogus calls to pg_free_result() that were inside of if 
> (!$result) {} blocks.

I updated the patch to try to replicate the way that read() and write() 
are done in mysql.php.

I have pgsql sessions working fine with turba, kronolith, nag, and gollem, 
but I can't get imp to work.


I have imp set as the default application.  After authenticating, imp 
displays the INBOX.  Selecting any message or trying to select an 
alternate mailbox results in imp re-displaying the INBOX.  If I use files 
or mysql to store sessions imp works fine.


It looks like _SESSION['imp'] is being overwritten with an empty array 
when using files.  The following edit to imp/lib/base.php always triggers 
with pgsql for me, but never with none/files.


if ($authentication !== 'none') {
     // If we've gotten to this point and have valid login credentials
     // but don't actually have an IMP session, then we need to go
     // through redirect.php to ensure that everything gets set up
     // properly. Single-signon and transparent authentication setups
     // are likely to trigger this case.
     if (empty($_SESSION['imp'])) {
         if (strstr($_SERVER['PHP_SELF'], 'compose.php')) {
             require IMP_BASE . '/recompose.php';
         } else {
print "<pre>_SESSION['imp'] is empty\n";
print_r($_SESSION['imp']);
print "</pre>";
exit;
             require IMP_BASE . '/redirect.php';
         }
         exit;
     }

     if (strstr($_SERVER['PHP_SELF'], 'compose.php')) {
         if (!IMP::checkAuthentication($authentication, true)) {
             require IMP_BASE . '/recompose.php';
             exit;
         }
     } else {
         IMP::checkAuthentication($authentication);
     }
}



Inserting

   print "<pre>"; print_r($_SESSION['imp']); print "</pre>";

before the footer is printed in mailboxes.php always shows data, so the 
data is being re-generated at some point in the redirects.


I haven't had time to look into it very deeply, but maybe somebody else 
has some ideas.



-Chris