[imp] VERY obscure bug just waiting to bite someone....

[Henry Blackman]

---------------------- multipart/mixed attachment
Hi James,

I would be very happy for people to see my code... I'm attaching it here.

It's based on the phpbuilder code with some modifications to make things
work better for my lovely users. Basically it resets the expiry every time
the session is read (so not necessarily writing data, but reading data keeps
the session fresh).

My session handler also follows the phpbuilder convention and does delete
the session when session_destroy() is called.  That, to me, seems quite
logical although I'm happy to change if this is prove to be incorrect.

The only time I came across the issue with "Document Contains No Data" was
indeed resolved by removing the same line as you removed, however when I
made the change in the session script and put the line back into IMP all was
well.

In addition, I must point out that the reason we went with a MySQL session
handler was because our IMP, Intranet (Document Management System) and other
Intranet services are provided over quite a few different servers (in total:
7 with a maximum 12,000 users)  and it was our only solution to access were
we don't involve NFS (which we don't trust).  We've been running with the
MySQL session since betas of PHP4 and until the recent upgrade to 4.1.1 we
didn't have any problems, and with our minor correction no more problems at
all.

Cheers,
Henry

----- Original Message -----
From: "James Noyes" <jnoyes-horde@retrogeeks.com>
To: <imp@lists.horde.org>
Sent: Thursday, February 21, 2002 12:19 PM
Subject: Re: [imp] VERY obscure bug just waiting to bite someone....


> On Thu, 21 Feb 2002 11:53:27 -0000
> "Henry Blackman" <h.blackman@chester.ac.uk> wrote:
> > You make a good arguement, but I've been using a MySQL session based
> > architecture for some time I have had no problems with it.  However I
> > wonder if you have a slight bug in your session code?
> >
> I'd be VERY interested in seeing your Session Manger code to compare it
> against mine.  I'll also point out that I am using IMP authentication for
> all of Horde. That may be important, since the imp/login.php?reason=logout
> is what my site calls for the "log out" link and it's IMP's login.php, not
> Horde's that has the issue.
>
> > For example, I constantly see errors in people's USER DEFINED code, in
> > their session read function whereby if there is on session data, their
> > function returns "false".  That's wrong, it must return '' (two single
> > quotes - ie. nothing).  I've seen this time and time again, so why don't
> > you check your code for that bug - it can't hurt.
> >
> This common mistake is discussed in MANY places, and the MySQL session
> management code I am using does NOT do this.  The problem I discovered
> actually *occurs* when a zero-length string is correctly returned.
> Returning the FALSE constant just causes apache to seg-fault, and that is
> not what I was experiencing.
>
> > Your statement where the USER is responsible for session clear-up.  You
> > are wrong.  That's what garbage collection does.  You should have a
> > function that takes care of that, and your php.ini should specify what
> > percentage of times it should be called during a session operation
> > (defaulting to 1 percent).
> >
> Perhaps I didn't clarify my use of the word "your".  The built-in
> file-based PHP sessioning's garbage collection does not purge old files
> from /tmp (or wherever it stores them).  Therefore it IS in fact "your"
> responsibility ("you" in this case being the person responsible for
> operation of the web server or the site that uses the sessioning) to clean
> up session files that haven't been accessed in some length of time.  As
> for the garbage collection function inside a user-defined session manager,
> well, if "you" wrote the session manager code, then as the author doesn't
> that make it "your" responsibility?  Semantics, I know.  I never said the
> USER (most certainly not the end-user accessing the web site) was
> responsible for this cleanup.
>
> James
>
> --
> IMP mailing list: http://horde.org/imp/
> Archive: http://marc.theaimsgroup.com/?l=imp&r=1&w=2
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: imp-unsubscribe@lists.horde.org
>
>

---------------------- multipart/mixed attachment--