Joseph Sliker;11023637 wrote:I have the login script look up a bunch of related user info and dump it into a $SESSION: (ie. $SESSION[USERSTUFF]) so that will be available to use in hidden form variables
That seems rather silly. Why spit out some data in a hidden element that the client has to spit back at you despite the fact that you'll already have the data in the session?
Joseph Sliker;11023637 wrote:I have never done anything fancy like attempting to set cookies on user's machines (due to my limited knowledge of what that might do to their machine and/or what sort of interference it could encounter from security software).
Oh, so you aren't using cookies to propagate the PHP session ID? In other words, you're either including the SID in a form element or in the query string for each request?
I only ask because the passing of the SID is a pretty vital (and arguably one of the most difficult) steps in getting PHP sessions to function. Thus, the exact method(s) you employ to do this are likely relevant for us to understand what's happening.
Joseph Sliker;11023637 wrote:Any comments/suggestions about how to insulate MY $_SESSION[USERSTUFF] from whatever OWA destroys upon exit?
Well first we'd have to know how the SID is getting passed for PHP sessions (sound familiar? :p). If it's via cookie, then my first thought would be to look at the HTTP headers OWA sends when you attempt to log out. That would tell you exactly which cookie(s) it is attempting to modify or destroy. If it's sharing the same name as your PHP cookie, then you'll probably want to rename the latter.
If it doesn't appear to have any direct correlation, then I'd start examining the HTTP headers your browser and the server exchange between a request where the session works and the next request where it doesn't.
