Hi,
I was trying the simple examples in Chapter 2. On page 51, I am able to see the result of the PHP script (number of days) but if I do view source, I don't get any HTML. It would only show me the actual PHP script in notepad.
More importantly, In chapter 3 page 76-77. In the browser I don't see the Author's name when it comes back from the server. Meaning that I type it in at the prompt and press submit. On the next screen in the address line I see: http://locaalhost/text.php?Author=john but I don't see the word "John" in the client browser.
I am using Windows XP (with IIS installed) and client and server both on the same machine. I also tried it on Windows Advanced Server 2000 and the same result. The example on page 92 doesn't work either. I haven't tried others but I assume the same for them.
What am I missing?

Thanks
Merdaad

http://p2p.wrox.com/archive/beginnin...2002-11/17.asp
http://p2p.wrox.com/archive/beginnin...2002-09/63.asp
http://p2p.wrox.com/archive/beginning_php/2003-02/3.asp
http://p2p.wrox.com/topic.asp?TOPIC_ID=4017

ad nauseum... =)


Take care,

Nik
http://www.bigaction.org/

Hey mkoohian! I'm a newbies in PHP and I had the same problem that you have, I resolved that problem using the variable echo $_REQUEST["Author"]; instead echo $Author; now its working for me. I was reading through PHP.INI and found this information:


Global variables are no longer registered for input data (POST, GET, cookies, environment and other server variables). Instead of using $foo, you must use you can use $_REQUEST["foo"] (includes any variable that arrives through the request, namely, POST, GET and cookie variables), or use one of the specific $_GET["foo"], $_POST["foo"], $_COOKIE["foo"] or $_FILES["foo"], depending on where the input originates. Also, you can look at the import_request_variables() function. Note that register_globals is going to be depracated (i.e., turned off by default) in the next version of PHP, because it often leads to security bugs. Read http://php.net/manual/en/security.registerglobals.php for further information.


Please correct me if im wrong.

$_REQUEST will work, but you shouldn't use $_REQUEST unless you don't know where data is coming from. This superglobal variable array is populated with a combination of $_GET, $_POST and $_COOKIE data. The order in which data is populated into the array depends on the setting of this directive in php.ini:

variables_order = "EGPCS"
ENVIRONMENT, GET, POST, COOKIE, and SESSION (EGPCS)
This is the default configuration, but because this can be changed it is not to be trusted.

If you expect data to be submitted by the get method, use the $_GET superglobal. If you expect it from post, use $_POST. If the same data may come from either get or post then use $_REQUEST. Because this variable is populated in the same way that the old register_globals directive was populated (using the above directive) it can give way to some of the same insecurities that made site's vulnerable to attacks using the register_globals directive.

For more information on this have a look at the plethora of links that Nik posted in a previous reply which addresses these very issues and sheds light onto how a hacker can break code using this vulnerability.

See also:
http://www.php.net/manual/en/languag...predefined.php

Inter95 - You are on the right track!
The truth of the matter is no matter whether you use the $_REQUEST variable or not, if your code is intelligently designed with these weaknesses in mind you will avoid any potential attack.

The register_globals directive has been deprecated since PHP 4.2.0 (current version is 4.3.4 and 5.0 is in beta testing), so it is already imperative to move away from using this functionality as some future version of PHP won't even include it.

: )
Rich

:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::

One more thing --
I would suggest that if you don't know where your data is coming from, your application isn't written very well. For the sake of security and clarity, you should ALWAYS specify $_GET, $_POST, $_SESSION, $_COOKIE, $_SERVER, or $_ENV to access variables that PHP creates for you. Using $_REQUEST to access variables basically ignores the reason that register_globals is off in the first place.



Take care,

Nik
http://www.bigaction.org/

Well I don't think that is true at all.
There are some cases when the data passed can be $_GET or $_POST either and it be perfectly fine to throw in the $_REQUEST variable and not have one single effect on security.

If the data is imperative to maintaining security then I would agree. And I would suggest that if that route is taken that validation be implemented.

The idea isn't that register_globals is bad, the idea is that register_globals CAN be bad if used poorly -- the cases that you present for breaking code are easily repaired and prevented. If I'm designing, let's say some sort of preview app for submitted data and passing a unique id of some sort to the app, and making that application double as the viewer for that data, then instead of writing extra code to use both get and post, I'm going to use request, it makes more sense! If that unique id has anything to do with security then, validate it! Check for data from unsavory sources and ensure that it doesn't get changed to something that it shouldn't be. Which was the point that I made.

: )
Rich

:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::