php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21312 session_register doesnt like null values
Submitted: 2002-12-31 08:59 UTC Modified: 2003-06-02 11:10 UTC
Votes:30
Avg. Score:4.8 ± 0.6
Reproduced:23 of 24 (95.8%)
Same Version:18 (78.3%)
Same OS:12 (52.2%)
From: charlesk at netgaintechnology dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4.3.0 OS: Windows 2000 Server
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: charlesk at netgaintechnology dot com
New email:
PHP Version: OS:

 

 [2002-12-31 08:59 UTC] charlesk at netgaintechnology dot com
<?php
session_start();
$source = $_SERVER["HTTP_REFERER"];
session_register("source");

$connection = mssql_connect('server','UserName','password');
$sql = "select * from tbl;";

echo "$sql $connection<br>";
$sql_result = mssql_query($sql,$connection);
$num = mssql_num_rows($sql_result);
$retVal = "Records = ".$num;
if ($num > 0) {
   mssql_data_seek($sql_result,0);
   $row = mssql_fetch_object($sql_result);
   $retVal = $row->Text;
}
mssql_free_result($sql_result);
echo $retVal;
?>

In this case the mssql_query fails with:
PHP Warning:  mssql_query(): supplied argument is not a valid MS SQL-Link resource.

if I simply comment the $source = $_SERVER... it succeeds.

If I change session_register to $_SESSION["source"] = $source; it succeeds.

I am not sure how these are related.

What is even weirder is the echo "$sql $connection<br>";
They echo what is expected when it works.  When it doesnt whichever was defined first is the value for both.

IE When it fails as it is written
select * from tbl_Texts; select * from tbl_Texts;

If you change 
$connection = mssql_connect('server','UserName','password');
$sql = "select * from tbl;";

to
$sql = "select * from tbl;";
$connection = mssql_connect('server','UserName','password');

it echos
Resource id #3 Resource id #3

I will in the future use $_SESSION but there are alot of files to change if this wont be fixed.

Thanks
Charles Killmer

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-01 12:19 UTC] phpbug at dpits dot de
i've the same problem with linux (apache 1.3.27) + mysql.
contents of nearly all variable are exchanged!

with a small function i had fixed this temporarly:

function dp_session_register($variable) {
  global ${$variable};
  if(is_null(${$variable}))
    ${$variable}="";
  return session_register($variable);
}

i hope, this will fixed as soon as posible. thanks.
daniel prior
 [2003-01-03 10:22 UTC] rasmus@php.net
Try adding this to your php.ini file:

session.bug_compat_42 = 1
session.bug_compat_warn = 0
 [2003-01-03 10:38 UTC] charlesk at netgaintechnology dot com
Tryed that and still the same results.
 [2003-01-12 13:06 UTC] charlesk at netgaintechnology dot com
Is anyone taking a look at this?  I just want to know how long I should wait.

Sorry if this sounds impatient, it isnt meant to be.  I am just wondering.  :)

Charles
 [2003-01-14 19:14 UTC] mmm at plesk dot com
PHP 4.3.0, Apache/1.3.27, RedHat Linux 7.3.

The same problem with Horde webmail. Webmail works fine,
but it shows that f warning each time on login page:

Warning: Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0

I've tried to play with
register_globals
session.bug_compat_42
session.bug_compat_warn
in /etc/php.ini file, each time I've restarted apache
of course :) but no luck.

Please, tell me what's wrong?
 [2003-02-04 15:41 UTC] jseverson at myersinternet dot com
I reported this same bug back in November of last year, and have had no luck with anyone at php.net replying with any acknowledgements to the bug or fixes.

Here is the link to the bug I reported, with some of the php.net developers' replies.

http://bugs.php.net/bug.php?id=20583
 [2003-02-04 15:47 UTC] charlesk at netgaintechnology dot com
Why has nobody from PHP looked at this in a month?

I would like to start using 4.3.0.
 [2003-02-21 12:46 UTC] jseverson at myersinternet dot com
This is causing me major headaches. Any word on this bug yet?
 [2003-03-14 08:46 UTC] thomas dot hoppe at damlerchrysler-bank dot com
I think I've encountered exactly the same bug (?):
After registering a null-value my complete session is messed up (most - didn't check whether all - variables are also null). Maybe this is caused by mixing $_GET... with register_globals = on and session_register(...) - which I do currently to migrate to register_globals = off.
 [2003-03-14 09:03 UTC] thomas dot hoppe at daimlerchrysler-bank dot com
Almost forgot:
I worked around by casting to a string.
 [2003-03-18 08:51 UTC] s at nospam dot org
still it is in the latest cvs and snaps. this problem being ignored?
 [2003-03-23 17:05 UTC] nez at irc dot pl
I've set:
error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
(even with error_reporting = E_ERROR it works ok)
and there's no more that problem - i mean no warning:

"Warning: Unknown(): Your script possibly relies on a session side-effect
which existed until PHP 4.2.3. Please be advised that the session
extension does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and this
warning by setting session.bug_compat_42 or session.bug_compat_warn to
off, respectively. in Unknown on line 0"

Or.. you can always set register_globals = Off ... ;-)
 [2003-03-25 09:01 UTC] roland at web dot co dot th
Yes, it appears that
error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
is currently the most efficient work-around until the developers come up with a response.

Has anyone a snipset how to code the sessions "clear" without causing that message at all?
 [2003-05-10 19:31 UTC] rrichards@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 [2003-05-21 15:51 UTC] bex at bex dot ca
I've had this same problem.  It came from setting session variables and worked fine in older versions of PHP but started giving me the mentioned error when PHP hit version 4.3.1.

<?
global $my_session_variable;
session_register("my_session_variable");
?>

OUTPUT HTML:
"Warning: Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0"

This comes from a misconception that you have to set a variable to global before it can be registered as a session.

Hope this helps in any way.
 [2003-05-30 10:06 UTC] adam at forsalebyowner dot com
On Linux 2.4x and Apache 1.3.27 with mod_perl and php 4.3.2 or 4.3.1, I get the same thing.  The root of the problem for me was the variable used:


$iAccountNumber     = $_POST['iAccountNumber'];
$_SESSION['iAccountNumber']     = $iAccountNumber;

throws out that error if the previous page does not have a post field for iAccountNumber.  Man, this took forever to figure out.  The funny thing is that the first line survives, it's the second one that makes the error spit out (assumedly because $iAccountNumber never gets set).  Neither of the session.bug_compat_42 or session.bug_compat_warn has any effect.
 [2003-06-02 11:10 UTC] charlesk at netgaintechnology dot com
This bug does not appear for me in 4.3.2 Windows 2000 SP3.

Thank you
Charles
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 20:01:29 2024 UTC