[dev] [cvs] commit: horde/services/portal sidebar.php

[Michael M Slusarz]

Quoting Michael M Slusarz <slusarz at curecanti.org>:

> slusarz     2005-05-15 20:53:28 PDT
>
>  Modified files:
>    services/portal      sidebar.php
>  Log:
>  We can't use 'readonly' in the sidebar as, for whatever reason, it causes
>  failed logins on the next link followed *after* all pages are loaded.
>
>  Revision  Changes    Path
>  1.14      +1 -2      horde/services/portal/sidebar.php

My additional 2 cents:
Reading session_write_close() documentation, I get the feeling that 
session_write_close() does not actually prevent you from 
accessing/writing the $_SESSION variable after calling it.  Its only 
functionality seems to be a way to tell the script to release the lock 
on the session file since we are sure there is going to be no more 
accesses/writes to the $_SESSION variable.  It doesn't appear to "lock 
out" the session and prevent further accesses to it - the function 
seems to assume that you, as programmer, must make sure you don't try 
to save to $_SESSION any further in your script.

In the current case, it seems like the following was happening:

1. sidebar loads
2. session "closed" in sidebar
3. inner frame loads
4. inner frame accessing/changes $_SESSION variable
5. sidebar accesses/chages $_SESSION variable (in IMP, for example)
6. inner frame closes $_SESSION variable at end of page

I think what is happening is action #5 is saving information to the 
$_SESSION variable without locking and so $_SESSION is becoming 
corrupt.  This error doesn't
show up 100% of the time since the timings of the script may cause the 
inner frame to close (or not even be opened yet) when #5 occurs.  Since 
the session data
is partially corrupt, PHP ends the session.  However, it appears that some PHP
session data must still be present as I can simply click on another 
link in the
sidebar (without entering username/password) and the sessions "revives" 
itself a
nd continues on.

We haven't seen this before because I believe the only other place we 
use 'reado
nly' sessions are in view.php scripts, for example, where we *do* know 
that we a
re not changing $_SESSION at all during the pageload.

Don't know if this analysis is worth anything, but thought I would 
share it for future development purposes.  I think this reversion makes 
the Bug dealing with concurrent DB session accesses even more critical.

michael

_______________________________________
Michael Slusarz [slusarz at curecanti.org]