My understanding of the issue is that thread safety is only a concern
with PHP's modules, not any code that may be written in PHP.

---

So was mine, but you know, when you're out of clues,
you start clutching at straws...

----
Well, as you mentioned, your problem is strange enough that I don't have
any good idea what would be causing it. Are you using the
PHP3-compatible session class for PHPlib pretty much as-is, or have you
modified it somehow? If you're using the User class, same question. The
problem you describe would have to be in one of those two areas--you
might want to make sure that your class isn't getting confused with user
data and session data, since they're both stored in the same table by
default.
----

No, I'm using only standard old-style session code, with "multi-record"
session (but every time I checked there wasn't any session data spawning
more than one record). And i use also auth (still "vanilla" phplib code)
and sometimes perm (this is a custom made version).

----
Upgrading to session4 may help you--and it may not. But it's something
to try. If you can send more details about what exactly is going on
(maybe you can add some debugging code to your scripts that prints
messages to a log or something), then I might be able to give a better
answer.
-----

It's really hard to figure what to log and/or debug. There are 2 incident,
in different installations, that I've witnessed in person:

1) in an application I used session to store the values users submit in a
complex input form (so the application "remembers" them each time they have
to input data again). At one time a user went to the form and found default
values that was clearly inserted by another user. No warnings, no errors,
looking in auth_Sessions table and in apache logs I didn't find any clue.

2) in another application i've put a "status" line at the end of every page
that echoes $auth-> auth["uname"]. I received a call from an user that
complained to have wrong permissions, so I asked him to read what was
written in the status line: well, it was the name of a different user, that
at that moment was logged in and working from a different client! This
REALLY sent me shivers thru my back. Note that first user's PC is not used
by the second one, and that first user does not know second user password.
So this was not a failed login for sure. I asked the user to logoff and to
login again, no problems, apparently all worked correctly again.
Some other info: I use only cookie for session propagation (i've disabled
get mode, no fallback). In case 2) there was a proxy in between both users
and the servers. In case 1) surely they were connecting via different
network routes.

I'm going to try swapping to session4 code, to see if something changes.
Thank you again for your feedback!

PS: please excuse me for the bad quoting form. Sadly i'm forced to use a
braindead mail client.




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Phplib-users mailing list
Phplib-users@[...].net
https://lists.sourceforge.net/lists/listinfo/phplib-users