I've encountered a very odd issue in regards to session variables and local variables in php.
I'm trying to figure out if I am not understanding something about sessions in php or if this is an issue with the php version my host is using.
Here is a very simple code to demonstrate the weird issue:
session_start();
var_dump($kenny);
var_dump($_SESSION['kenny']);
$_SESSION['kenny']='def';
var_dump($kenny);
var_dump($_SESSION['kenny']);
$kenny = 'abc';
var_dump($kenny);
var_dump($_SESSION['kenny']);
The first time I run the code, I get the following results (as one would expect):
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
I run it a second time (without closing my browser, of course), I get this now!
string(3) "def" string(3) "def" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
I run it a 3rd, 4th, 5th time and so on, I get this!!!
string(3) "abc" string(3) "abc" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
It looks to me like the session variable 'kenny' and local variable $kenny become aliases to one and the other after running the script more than once. hmm... I really don't think this is how session variables and local variables work in php. Please correct me if I'm missing something here.
My web host is running php 5.2.2. When I try this exact same code on other hosts running php 5.2.1, 5.2.14 and 5.3.1, they always give me what I expect:
1st time:
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
thereafter:
NULL string(3) "def" NULL string(3) "def" string(3) "abc" string(3) "def"
I checked the change log on php.net and didn't find anything that I can relate to that may address this issue. But like I mentioned, an earlier build (5.2.1) works ok, so that's very puzzling to me.
If anyone runs any other version of php 5.2.x, please give it a try and let me know if you see the same issue. Or if anyone has any insight into the issue, I'd really appreciate any feedback.
Thanks a million!
This is probably because the register_globals directive is on. It doesn't say it on that page that $_SESSION variables are included, but it says here:
If register_globals is enabled, then
the global variables and the
$_SESSION entries will automatically
reference the same values which were
registered in the prior session
instance. However, if the variable is
registered by $_SESSION then the
global variable is available since the
next request.
Related
<?php var_dump($argv); ?>
ok - run it directly - get what's expected.
$ php /tmp/check-arg.php -s test yellow bus
array(5) {
[0]=>
string(18) "/tmp/check-arg.php"
[1]=>
string(2) "-s"
[2]=>
string(4) "test"
[3]=>
string(6) "yellow"
[4]=>
string(3) "bus"
}
ok - so I want to run this script as if it were a command (it's a php script that replaces an existing command), so I created this script
$ vi /tmp/testingcommand
php /tmp/check-arg.php $1 $2 $3 $4 $5 $6 $7 $8 $9 $10
(edit - change the $10 to {10} is solution - or use "$#" instead of $1 $2...)
so I should be able to just
$ /tmp/testingcommand -s test yellow bus
array(6) {
[0]=>
string(18) "/tmp/check-arg.php"
[1]=>
string(2) "-s"
[2]=>
string(4) "test"
[3]=>
string(6) "yellow"
[4]=>
string(3) "bus"
[5]=>
string(3) "-s0"
}
OK - so where did that "-s0" come from? I've done some fiddling and it's what is in $argv[1] (-s) and a "0" (so in this case -s0)
Any ideas? happened on our RHEL7 as well as a Fedora 30 setup
since the script can be run either directly (php program.php) or via a script I can't just ignore the last index of argv[]
I guess I could check argv[0] for '...php' and keep all indexs and if no ...php then ignore last index
-s0 came from $10. That's $1 followed by 0.
Use ${10} to access parameter 10. You need curly braces whenever the parameter number is more than one digit.
Note that your code won't work properly if any of the arguments have spaces, because you're not quoting the variables. The variable value will undergo word splitting and wildcard expansion.
But if you quote all the variables, you'll get explicit '' values for the arguments that weren't supplied, which is probably not desired, either.
The correct way to reference all the arguments is with "$#".
php /tmp/check-arg.php "$#"
I'm running a code getting data from a DB server, everything is working fine locally. But when I push it online, it's not working anymore.
I think I know where the problem comes from. Here is the data I get locally:
object(stdClass)#451 (14) {
["matter_created_actionstep_c"]=>
string(1) "1"
["trust_receipt_sent_c"]=>
string(1) "1"
["scope_complete_c"]=>
string(1) "0"
["transferred_trust_to_current_c"]=>
string(1) "0"
}
And when I push it on my server, here is the result I get:
object(stdClass)#451 (14) {
["matter_created_actionstep_c"]=>
int(1)
["trust_receipt_sent_c"]=>
int(1)
["scope_complete_c"]=>
int(0)
["transferred_trust_to_current_c"]=>
int(0)
}
Are you aware of any apache configuration that would lead to this typeset change?
The only project file that is different, is the conf file:
locally:
DB_HOST=1.1.1.1
on the server:
DB_HOST=localhost
Thanks in advance.
This can result from a lot of issues. Maybe a different PHP version, maybe the data comes from a database and the version of the database driver is different, …
I would say the application is to blame. PHP is untyped, meaning in most cases nobody cares for the actual type of a variable. In your case barely anybody cares if the value is 2 or "2" as long as it behaves the same (e.g. 2==2 equals 2=="2"). If the application requires certain types in some variables, it should assure the variables contain these types! This is not the case here.
Check the application and the part of the code which writes the value into the object. This part of code should cast the value to the desired type before putting it into the variable.
Nevertheless (or if the object comes from somewhere else) it may make sense to make the code more forgiving concerning types, i.e. do not rely on a special type as long as it is not necessary. In my experience there are only few cases when type of variables really matter.
I've encountered a very odd issue in regards to session variables and local variables in php.
I'm trying to figure out if I am not understanding something about sessions in php or if this is an issue with the php version my host is using.
Here is a very simple code to demonstrate the weird issue:
session_start();
var_dump($kenny);
var_dump($_SESSION['kenny']);
$_SESSION['kenny']='def';
var_dump($kenny);
var_dump($_SESSION['kenny']);
$kenny = 'abc';
var_dump($kenny);
var_dump($_SESSION['kenny']);
The first time I run the code, I get the following results (as one would expect):
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
I run it a second time (without closing my browser, of course), I get this now!
string(3) "def" string(3) "def" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
I run it a 3rd, 4th, 5th time and so on, I get this!!!
string(3) "abc" string(3) "abc" string(3) "def" string(3) "def" string(3) "abc" string(3) "abc"
It looks to me like the session variable 'kenny' and local variable $kenny become aliases to one and the other after running the script more than once. hmm... I really don't think this is how session variables and local variables work in php. Please correct me if I'm missing something here.
My web host is running php 5.2.2. When I try this exact same code on other hosts running php 5.2.1, 5.2.14 and 5.3.1, they always give me what I expect:
1st time:
NULL NULL NULL string(3) "def" string(3) "abc" string(3) "def"
thereafter:
NULL string(3) "def" NULL string(3) "def" string(3) "abc" string(3) "def"
I checked the change log on php.net and didn't find anything that I can relate to that may address this issue. But like I mentioned, an earlier build (5.2.1) works ok, so that's very puzzling to me.
If anyone runs any other version of php 5.2.x, please give it a try and let me know if you see the same issue. Or if anyone has any insight into the issue, I'd really appreciate any feedback.
Thanks a million!
This is probably because the register_globals directive is on. It doesn't say it on that page that $_SESSION variables are included, but it says here:
If register_globals is enabled, then
the global variables and the
$_SESSION entries will automatically
reference the same values which were
registered in the prior session
instance. However, if the variable is
registered by $_SESSION then the
global variable is available since the
next request.
I am getting a new php warning when a POST data from a form on my page to my server. The warning is as follows:
PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer: https://mywebsite.com/index.php
The thing is that my form does not have near 1000 input variables, so I am baffled as to why this is appearing. As a side note, I have not had this problem until recently and I suspect that when I ran yum update something changed/was installed that is causing this. Any advice or answers are appreciated.
EDIT 1:
So I did var_dump($_REQUEST) and got ~1000 single character strings. The first couple items in the array are what they should be, but then a bunch of stuff that I don't need submitted is broken down into single character strings. Thoughts welcome.
array(1001) {
["action"]=> string(10) "step1_show"
["submit"]=> string(6) "Step 1"
[0]=> string(1) "a"
[1]=> string(1) "c"
[2]=> string(1) "t"
[3]=> string(1) "i"
[4]=> string(1) "o"
[5]=> string(1) "n"
[6]=> string(1) "="
[7]=> string(1) "l"
[8]=> string(1) "o"
[9]=> string(1) "g"
[10]=> string(1) "o"
[11]=> string(1) "u"
[12]=> string(1) "t"
[13]=> string(1) "&"
[14]=> string(1) "p"
[15]=> string(1) "r"
[16]=> string(1) "o"
[17]=> string(1) "p"
[18]=> string(1) "e"
[19]=> string(1) "r"
[20]=> string(1) "t"
[21]=> string(1) "y"
[22]=> string(1) "="
[23]=> string(1) "3"
[24]=> string(1) "7"
[25]=> .....
ANSWER: It ended up being a problem with my submit handler. Thanks all for your input.
That's a new setting / value in PHP (related to a security update to prevent attacks to PHP scripts), so you get this after the update (before PHP 5.3.9 not set/available, suhosin users have a similar thing since ages).
Input values are of different kinds and array members count as well. So it's not enough to count form fields but also to take a look into the URL and other places related to input ($_GET, $_POST, $_SERVER, $_ENV, $_FILES, $_COOKIE ...).
See max_input_vars:
How many input variables may be accepted. Use of this directive mitigates the possibility of denial of service attacks which use hash collisions. If there are more input variables than specified by this directive, an E_WARNING is issued, and further input variables are truncated from the request. This limit applies only to each nesting level of a multi-dimensional input array.
There is two way to solve this problem.
.htaccess
php_value max_input_vars 10000
php
ini_set('max_input_vars','10000' );
I was on my mac machine using Laravel valet... did followings to fix the error.
On terminal php --ini to find out loaded PHP configuration file.
sudo nano that file, in my case it was sudo nano /usr/local/etc/php/7.3/php.ini
ctrl + w to search max_input_vars
In my case it was ;max_input_vars = 1000
Updated to max_input_vars = 2000
Save file.
valet restart to update new configuration.
That worked :-)
I fixed the max_input_vars issue via my web host admin panel (Littleoak)
I changed the max_input_vars = 0 to max_input_vars = 6000.
There are several installations of php on my server that the server company configured. I believe the max_input_vars = 0 is to prevent email spammers from using the server to send spam. The php.ini file lives somewhere, not sure where, but I was able to modify it via the cPanel on my site admin.
I have the following code:
var_dump($cumulitive);
$y_axis_max = max($cumulitive)*1.3;
var_dump($y_axis_max);
It outputs the following:
array(16) {
[0]=>
int(0)
[1]=>
int(0)
[2]=>
int(0)
[3]=>
int(0)
[4]=>
int(0)
[5]=>
int(0)
[6]=>
int(0)
[7]=>
int(0)
[8]=>
int(0)
[9]=>
int(0)
[10]=>
int(0)
[11]=>
int(4)
[12]=>
int(4)
[13]=>
int(4)
[14]=>
int(9)
[15]=>
int(9)
}
float(NAN)
As you can see, $y_axis_max is giving NAN. So I try this: I restart WampServer. It works now. I refresh the browser. Works again. refresh the browser again. Now it doesn't work, and I can't get it to work again without restarting Apache. From the 3rd request on it stops working.
It USED to work just fine. Then I changed some things. Specifically, I modified my app to use the DateTime class in a few places. But that shouldn't make this strange error occur. Any ideas on how to debug this?
If I call the $y_axis_max = .. line of code twice in a row, then I get this for $y_axis_max:
float(#.7)
What the heck is that?
EDIT: Seems that calling DateTime::diff earlier causes the error. Any workaround ideas?
max() will work on arrays. Looks like you have some form of corruption in your code. If one of the elements in the array is a NAN you will get this result. Try testing a smaller script on your server in order to isolate the problem.
Seems that calling DateTime::diff earlier causes the error. I just used a work-around so not to use it.