persistence demo not persisting


#1

Heelo again, I am working through a ‘persistence demo’. According to the tutorial I am working on this should show me how variables can be made to persist. However, i get some error messages and I don’t understand the cause. Folloewing is my short PHP

[php]

persistence demo

Persistence Demo

<?PHP //increment the counters print <<<HERE

The hidden value is '$hdnCounter'

HERE; $txtBoxCounter++; $hdnCounter++; ?>

[/php]

OK the error messages are ‘undefined variables’ pointing to the lines where the variables are first used. This looks ok to me, so what am I missing??? please???


#2

I presume these are the lines:

[php]


[/php]

You’re using the variables before defining them, which is bad practice.
It’s best to use a construction like this:

[php]if (empty($txtBoxCounter)) { $txtBoxCounter = 0; }[/php]

Or something to that extent.

Furthermore, be sure to use the $_GET/$_POST superglobals and turn of register_globals.


#3

thanks for that, it seems to help. Although the tutorial I am trying to work through tells me to turn register_globals on.
Some of the work I have done works well with this on and not well with it off. I appreciate the security issues and still need to spend time to re-work those few problematic items…


#4

Turning on register_globals poses a serious security hole, and it’s best to turn it off and learn to work with the superglobals such as $_GET and $_POST. No matter how many tutorials tell you to turn on register_globals, it’s BAD PRACTICE.


#5

I would definatly have to agree with Zyppora here. Its always good practice to use the option that works both ways instead of realying on setting to be in place. Makes the application easier to setup and use in other places. Think of it this way… Using the good practice of using $_POST or $_GET will allow the application to work either with or without the register_globals on. If you do not use them and register_globals are off then you application is no good to anyone without doing some changing.

This is just on top of the main factor of security that Zyppora mentioned.


#6

Given that register_globals is turned off,
what syntax do the superglobals require. I have perused the online help here and at PHP.net but seem unable to work it out. Can you PLEASE give me an example of how superglobals would work in the above example??

I am not asking for a rewrite just an example that will allow me to learn how to do it myself…

Ghostrider1965

:(

#7

With register_globals on what happens is your scripts just pass the variables from a form to the script as is. So using

<input type = "text"
       name = "txtBoxCounter"
       value = "$txtBoxCounter">

The Variable Name is txtBoxCounter and the date is whatever value is contained in $txtBoxCounter

So on your first iteration, $txtBoxCounter should be empty (and undefined , thus the errors/warnings). Next time through, the script will see a variable called [/b]txtBoxCounter[/b] with whatever value was submitted.

Turning register_globals OFF means that your script does not automatically see the variable (and subsequent data) of $txtBoxCounter, but rather it puts all of the POST or GET data into a special array (Called the “SUPER GLOBAL” arrays.) Depending on the method you used to pass it (which confuses me about your form… You don’t specify the method or the intended action form, so I assume that it has some default like the GET method and the action form would be itself)

So to access the data in $txtBoxCounter (or other variables passed) you would need to utilize the appropriate super global. They are named, appropriately enough, as $_GET, $_POST, $_REQUEST, $_SERVER, $_SESSION, and more (see http://us3.php.net/variables.predefined for more details).

So you can now access the data passed using the get method from $txtBoxCounter like thus:

$_GET[‘txtBoxCounter’] where the “Passed” variable becomes the index of the Super Global array.

Now as Zyporra has stated in many posts, you should initialize variables, not just to avoid warnings (which could be shut off) but for security too. I use the Tertiary function:

[php]
$txtBoxCounter = !empty($_GET[‘txtBoxCounter’]) ? $_GET[‘txtBoxCounter’] : 0;
[/php]

The above is the equivalent to the below

[php]
if (!empty($_GET[‘txtBoxCounter’]) {
$txtBoxCounter = $_GET[‘txtBoxCounter’] ;
} else {
$txtBoxCounter = 0;
}
[/php]

As Ragster points out… using this method (of super globals) will work regardless of whether register_globals is on or off, however NOT using this method, and using your current method means that if SOMEONE else takes your code to use on their site, then they MUST turn register_globals ON. As Zyporra points out… This is a security hole and can lead to people not wanting to use your code.

I know I can get long winded but I hope this helps.


#8

The following are appropriate in use:

  • $_GET (usually used for URL query variables)
  • $_POST (usually used for form data)
  • $_COOKIE (usually used for data stored in cookies)
  • $_SERVER (server environmental data)
  • $_SESSION (data stored in a session)

Using the $_REQUEST superglobal is generally bad practice, but has its advantages. I suggest not to use this unless you know what you’re doing any any of the above does not suffice.

Almost :wink: Using an if statement might still present you with a notice or warning, as (and, for example, the Java compiler DOES complain about this) your variable MIGHT not have been initialized. Best is to prepend the if statement with:

[php]$txtBoxCounter = 0;[/php]

This would also allow you to omit the else structure, gives you cleaner code, etc. I’ll hold my thoughts about the tertiary function :X (just think: readability)

The security hole is basically a mixture of not initiating a variable and having register_globals turned on:

[php]<?php

if ($password == “mypassword”) {
$myVar = true;
}

if ($myVar == true) {
displaySensitiveData();
}
?>[/php]

You could have $password be a password coming from a form on another page. However, I could easily bypass the password check by simply browsing to the following URL: yourpage.php?myVar=true

Without knowing the password, I’ve now succesfully unlocked the sensitive data :wink:

Naturally, it takes sloppy coding to come up with something like that, but there are many ways in which a security hole can sneak into your code. Best is to mitigate easy-to-kill security issues such as register_globals or variable initiation. error_reporting(E_ALL); will help you take down anything that might remotely pose a threat syntax-wise.


#9
:D