RE: [phplib] PHP4 session problems From: Hans-Jurgen Petrich (hans.petrich <email protected>)
Date: 01/29/01

Hi Shawn,

> Next came the problems of working with sessions within frames. I was
> getting the following error in 2 out of my 3 frames (although not always
in
> the same frame):
> Database error: Invalid SQL: insert into active_sessions ( sid, name, val,
> changed ) values (...)
> MySQL Error: 1062 (Duplicate entry '...' for key 1)
> Session halted.

I had the same problem, and as
Max A. Derkachev wrote: "... If you have 3 concurrent read/write session
objects, you'll
come into a trouble"

I change my source and call page_close() only in pages where necessary.
Perhaps you can modify your frameset, that only ONE page (in the frameset)
call page_close()

Or you can patch ct_sql.inc
and replace in ac_store()

if ( $this->db->affected_rows() == 0
      && !$this->db->query($iquery)) {
        $ret = false;
    }

TO

if ( $this->db->affected_rows() == 0
      && $this->db->query($squery)
      && $this->db->f(1) == 0
      && !$this->db->query($iquery)) {
        $ret = false;
    }

This works whith phplib-7.2b
I catch this peace source anywhere in this mailinglist, but i dont suggest
this patch
(somehow i think its dirty 2 do this :-)

Hope this will help you
Bye
Hans-Jurgen Petrich

-----Ursprungliche Nachricht-----
Von: Shawn Baker [mailto:shawn <email protected>]
Gesendet: Sonntag, 28. Januar 2001 20:27
An: phplib <email protected>
Betreff: [phplib] PHP4 session problems

Hi there. My name is Shawn, and while I've been programming avidly for 20
years, I'm new to the PHP world. I've done several static web sites with
plain old HTML, but I'm just starting into dynamic website technology.

A few weeks ago I started creating a web site for a new client using ASP
and an Access database (I needed to know something about it for work). It
wasn't too hard to get the basic site navigation and authentication
working, but I was aching to get into the open-source world. So I rewrote
the site using straight PHP and MySQL. It only took one weekend and I was
(am) _very_ impressed with both PHP and MySQL.

Then I started hearing about this thing called PHPLIB and I came to realize
that it had a whole pile of features I needed: sessions, authentication,
permissions, users, templates, and probably other stuff too. So I spent the
next weekend converting everything over to PHPLIB. And that's when my
problems began.

First of all, let me say that I'm doing my development on a Windows 200
Server box. I'll be deploying onto a Linux server, as soon as I get it up
and running. So all of my problems have been under Windows (so far).

My first problem was getting PHPLIB to work at all. I had installed the
Windows Installation Program version of PHP and maybe that was the problem.
Because when I uninstalled it and then installed the full version
everything worked fine. Of course it took me 5 hours to find that solution.

Next came the problems of working with sessions within frames. I was
getting the following error in 2 out of my 3 frames (although not always in
the same frame):

Database error: Invalid SQL: insert into active_sessions ( sid, name, val,
changed ) values (...)
MySQL Error: 1062 (Duplicate entry '...' for key 1)
Session halted.

(Note: I've replace the actual data with ...'s for clarity.)

I was able to track this down to the page_close() call and then to the
session saving code in the session class. It's basically a race condition
(I think) when several frames are trying to update the database at the same
time. After some more research it became apparent that I couldn't do
page_close() in all the frames. So I got rid of the page_close()'s in the
navigation frames and things got a lot better. But not perfect. I still get
the error once in a while and I have no idea why!

So I decided that the solution was to use PHP4 sessions. I had heard about
an implementation being in the CVS tree so I went to check it out. Man was
I disappointed! There were 3 different implementations and no indication as

to the differences, state of completion, stability, etc. Nothing! I
couldn't believe it. I thought this whole problem would have been dealt
with by now, but instead it looks like it's in its infant stages and not
very organized at that.

So I picked one of the three (Teo's) and started using it. And I
immediately ran into problems. For starters, no "freeze" method.

         First rule of new versions of anything:
                 Don't break the old versions!

So I added a stub and moved on, but who knows what else is missing. The
next problem was that self_url() didn't work. It was looking for an
environment variable (REQUEST_URI) that doesn't exist. So I looked at the
original session code and found that it was quite different. I tested it
and it worked.

         Second rule of new versions of anything:
                 Don't rewrite (for no reason) routines that are working.

So now I'm using the old routine and things are working OK. But now I'm
sceptical about that version of the session class (there are a lot of
differences between it and the original) and I'll probably try one of the
others. Of course, I may just be creating a new set of problems for myself,
but I've got to do something.

Now, onto the _real_ problem with PHP4 sessions. The problem only occurs
when using frames, but it's a biggy. With PHPLIB sessions, each frame has
its own copy of all the registered variables, including $sess and $auth.
When one frame changes a registered variable, that change is _not_ visible
to the other frames. With PHP4 sessions, the frames share one set of
registered variables, and changes to a registered variable in one frame are
immediately visible to the other frames.

This rears its head in an ugly way with default authentication. Default
authentication depends on the fact that each frame has its own copy of the
$auth object. If they share an object, then the real authentication in one
frame interferes with the default authentication in the other frame(s).
Both frames are trying to set the $auth instance variables to different
values. Needless to say, the results will be unpredictable at best. You'll
either get the login form in all the frames, default authentication in all
the frames, or some seemingly random combination.

I've fixed the $auth class for myself by adding a parameter to the start()
method, forcing it to simply return true. It's a quick fix which probably
isn't suitable as a real solution. I suspect the $auth class will need a
bit of rewrite. Which is fine by me because that $nobody business is an
ugly solution to a required feature (IMHO).

The other potential problem that I can see with PHP4 sessions is that when
registered objects are restored in a new page, _all_ of the instance
variables will be restored, not just the ones specified as having
persistent slots. Any object that depends on this behaviour will now break.

Anyway, my real concern is how PHP4 sessions will affect PHPLIB as a whole.
I don't know the library well enough to say what else might be affected,
but I think somebody should look into it (somebody who knows the code well).

Shawn Baker
shawn <email protected>
http://www.frozen.mb.ca

---------------------------------------------------------------------
To unsubscribe, e-mail: phplib-unsubscribe <email protected>
For additional commands, e-mail: phplib-help <email protected>