ID: 15551
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Session related
Operating System: Win32
PHP Version: 4.1.1
New Comment:
[EMAIL PROTECTED] wrote:
> If you cannot control the setting of register_globals,
> you should use the session_register() functions
while earlier he wrote:
> If you are using $HTTP_SESSION_VARS/$_SESSION, do not use
> session_register(), session_is_registered() and
> session_unregister() unless you know internal of session
> module.
> In other words, don't use register_globals(on) and
> $_SESSION together.
So then, how exactly am I supposed to make sessions work if I can't
access the session arrays? $GLOBALS? $_GLOBALS?
$*GLOBALS != sessions.
I must admit that I'm sorely disappointed in the way PHP development
has been proceding as of 4.0.6 Sessions are horribly broken, the
documentation is just plain wrong, there's very little developer
support, and the default answer to every session problem seems to be
'don't use session_* with any of the session arrays. Don't use any of
the session arrays if the ini file has been modified from the defaults.
Learn the internals of the session module."
Which leavs PHP, for all intents and purposes, without session
support.
Might I suggest the developers and documentation maintainers advise
against the use of sessions until such time as they work? With 'work'
defined as backward-compatible with prior versions of PHP AND (this is
important) functional with respect to what the documentation says.
I really don't feel like should have to grok the internals of the
session module just to be able to use sessions. This is why the
session module is a module (module being defined as a black box
componant).
HAND
Previous Comments:
------------------------------------------------------------------------
[2002-02-14 12:17:29] [EMAIL PROTECTED]
Funny guy, as you could see in my demonstration script, I'm capable of
unregistering variables from session having register_globals enabled. I
just don't like the way how that has to be done.
By and by I get tired of writing new workarounds for new bugs (from
which almost all were session related). My session handling class
meanwhile contains three workarounds, which are applied depending on
the php version and its configuration. If session handling would work
as expected, I wouldn't have to use my (workaround-bloated)class
anymore.
Furthermore it makes no sense to me, to introduce a new clean way of
handling session variables, while making it impossible to be used by
developers that have to consider backwards compatibility. (By the way,
I belive this silly behaviour could be fixed ...)
------------------------------------------------------------------------
[2002-02-14 09:11:21] [EMAIL PROTECTED]
If you cannot control the setting of register_globals, you should use
the session_register() functions _or_ learn the internals of the
session module :)
Regards, Marc.
------------------------------------------------------------------------
[2002-02-14 08:28:51] [EMAIL PROTECTED]
And how I'm supposed to write good, compatible code while I can't tell
my customers what they have to configure on their server, because my
application is not supposed to be the only one running there?
If the references would point to $_SESSION[*] and be stored in
$GLOBALS[*] instead of pointing to $_GLOBALS[*] and being stored in
$_SESSION[*], you could use $_SESSION[*] regardless of
register_globals.
------------------------------------------------------------------------
[2002-02-14 07:16:42] [EMAIL PROTECTED]
extract from the session documentation:
If register_globals is enabled, [...] users must register variables
with session_register() function.
If you are using $HTTP_SESSION_VARS/$_SESSION, do not use
session_register(), session_is_registered() and session_unregister()
unless you know internal of session module.
In other words, don't use register_globals(on) and $_SESSION together.
Regards, Marc.
------------------------------------------------------------------------
[2002-02-14 06:22:07] [EMAIL PROTECTED]
Hi F0lks,
when I use the $_SESSION array while register_globals is enabled, I
can't unregister variables as described in the documentation (
unset($_SESSION['var']); ), except in the script call where 'var' was
used first time.
I wrote demonstration script hoping it shows you what I mean.
(register_globals must be enabled!)
<?
session_name('testsession');
session_start();
echo '<pre>';
if( ! $_SESSION['c'] ) $_SESSION['c'] = 1;
echo "=== unregistering variables from session with register_globals=On
under PHP 4.1.1 ===\n";
echo "Current step: $_SESSION[c] of 5\n\n";
switch( $_SESSION['c'] ) {
case 1:
echo "Checking, if 'var' is registered - ";
if( session_is_registered('var') ) {
session_destroy();
echo "yes. Killed session. END. (reload this page!)\n";
die();
} else {
echo "no. Good.\n";
}
echo "Setting \$_SESSION['var'] to 'test1' ...\n";
$_SESSION['var'] = 'test1';
varcheck( true );
break;
case 2:
varcheck( true );
echo "Trying to unregister 'var' with unset(\$_SESSION['var'])
...\n";
unset( $_SESSION['var'] );
varcheck( false );
echo "\$_SESSION['var'] isn't anymore now, so it shouldn't exist on
the next step.\n";
break;
case 3:
varcheck( true );
echo "Here it is again, damn!\n";
echo "Trying to get rid of it with session_unregister('var') ...\n";
session_unregister('var');
varcheck( false );
echo "Maybe, this time, it won't come back ...\n";
break;
case 4:
varcheck( false );
echo "It worked, \$_SESSION['var'] is dead ...\n";
echo "so let's try registering and unregistering in one (this) script
call.\n\n";
echo "Setting \$_SESSION['var'] to 'test2' ...\n";
$_SESSION['var'] = 'test2';
varcheck( true );
echo "Trying to unregister 'var' with
unset(\$_SESSION['var'])...\n";
unset( $_SESSION['var'] );
varcheck( false );
break;
case 5:
varcheck( false );
echo "No \$_SESSION['var'] ...\n\n";
echo
'I think, I can explain this behaviour.
When you register a variable by $_SESSION[\'varname\']=\'something\';
$_SESSION[\'varname\'] is a string. When the script reacheas its end,
it
sees no $GLOBALS[\'varname\'] to save (register_globals=On!) so it
takes
$_SESSION[\'varname\'].
When calling the script again, \'varname\' will be restored from
session
to $GLOBALS[\'varname\']. Then a reference to $GLOBALS[\'varname\']
will
be created in $_SESSION[\'varname\']. unset($_SESSION[\'varname\']
would
only delete the reference to $GLOBALS[\'varname\'] ...
My suggestion to the php developers:
When register_globals=On restore variables from session to
$_SESSION[\'varname\'] and store a reference to it in
$GLOBALS[\'varname\'].
';
// don't need break; here ...
default:
session_destroy();
echo "\n- - -\nSession killed. END. (reload to start again)\n";
die();
}
$_SESSION['c'] += 1;
echo "</pre><a href=\"$PHP_SELF\">next</a>";
function varcheck( $y, $ignore=false )
{
$x = isset( $_SESSION['var'] );
if( $x ) {
echo "\$_SESSION['var'] is now: ";
var_dump( $_SESSION['var'] );
} else
echo "\$_SESSION['var'] is not set.\n";
if( $x != $y and !$ignore ) {
echo "... this shouldn't happen, maybe your php.ini differs from
mine.\n";
echo " feel free to contact me
<[EMAIL PROTECTED]>\n";
die();
}
}
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=15551&edit=1
