Edit report at https://bugs.php.net/bug.php?id=61932&edit=1
ID: 61932
Updated by: yohg...@php.net
Reported by: hans dot rudolf dot w at hotmail dot com
Summary: garbage collector destroys session of caller, no
write
-Status: Open
+Status: Wont fix
Type: Feature/Change Request
Package: Session related
Operating System: ubuntu
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
I think you are having too short session.gc_maxlifetime(default:1440 sec) or
session.cookie_lifetime(Default 0. 0 is good for almost all app, though) for
your
needs.
Increase session.gc_maxlifetime, since executing gc before open/read cannot be
an
option.
Previous Comments:
------------------------------------------------------------------------
[2012-11-17 22:20:26] jeffrey dot haley at gmail dot com
I believe i'm experiencing the same issue. Could you provide some more detail
on
how to reproduce the issue?
------------------------------------------------------------------------
[2012-05-03 21:04:27] hans dot rudolf dot w at hotmail dot com
Description:
------------
The order is session open, session read, session gc.
This applies to the case where the garbage collector is triggered by the client
X and the session is of client X.
The session variables are available in script, but the sessionfile is deleted
and no write of the session takes place.
For the php user and the php application user there is the impression that the
session still is alive.
Example:
User is logged in with cookie with sessionid in an admin application and is
logged in as admin which is registerred in the session.
Has admin form bookmarked or in history.
Php script does gc removes sessionfile.
But the session variables indicate that the user is logged in and so the script
spits out the form.
User does a post and poof suddenly there is no session.
This is seemingly random behaviour and no ordinary php programmer and user has
any idea what is going on.
This sounds like one in a million but could happen quite often with a database
application in a small business.
So either the session should be removed before open and read, which I
understand
you won't do (Bug #35479)
or it should be continued and rewritten to file, which is what the bahaviour
when you write the most straightforward handler for a session database
Also as a dev. how do I know it is garbage collected?
Test script:
---------------
setup:
ubuntu package mod php 5.3.10 on apache2 mpm prefork
relevant and changed ini setting:
session.gc_maxlifetime = 1
session.save_path = /tmp
Expected result:
----------------
session that is garbage collected by invocation of session owner (http client)
is
rewritten to a new file
Actual result:
--------------
session variables are available but session is effectively destroyed, giving
the
impression that the session is still live when it is not
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=61932&edit=1
