p2p.wrox.com Forums

Need to download code?

View our list of code downloads.


  Return to Index  

beginning_php thread: $_REQUEST includes form posts?


Message #1 by spam@k... on Mon, 16 Sep 2002 23:34:51 -0500
Been asked to install my simple CMS on a site. Told I should use the pre-existing database class and
user ID class for login. Not a problem. Good for me to read the code of a better programmer. Ran into the array $_REQUEST in the
following lines: 


// The next 4 lines are Costin's security stuff.
$s = new CSafe();
if ($_REQUEST['act'] == "logout") $s->logout();
elseif ($_SERVER['REQUEST_METHOD'] == "POST" && $_REQUEST['act'] == "login") $s->login($_POST['login_u'],
$_POST['login_p'], (int)$_POST['login_cookie']);
else $s->auth();


Looked it up on www.php.net:

"An associative array consisting of the contents of $_GET, $_POST, $_COOKIE, and $_FILES. This is a 'superglobal', or automatic
global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do a global $_REQUEST;
to access it within functions or methods. If the register_globals directive is set, then these variables will also be made available
in the global scope of the script; i.e., separate from the $_REQUEST array. For related information, see the security chapter titled
Using Register Globals. These individual globals are not autoglobals." 

Looked for $_REQUEST['act'] but didn't find it. This needs to be handed to the script from a form, I guess? I need to create a form
with that as one of the variables being handed in, right?

Probably should just go do it rather than ask. Just never used objects before. It's all a bit thick. 



Message #2 by "Nikolai Devereaux" <yomama@u...> on Tue, 17 Sep 2002 08:44:07 -0700
$_REQUEST is a strange variable... it basically gives you the inconvenience
associated with register_globals = off, but still has one major drawback --
if you have two different superglobals with the same index defined, one of
them will overwrite the other.

For instance, let's say you store the current logged in user's info in a
session variable (as many people do).

// these are dummy values for the purpose of example:
$_SESSION['userid'] = 4;
$_SESSION['access'] = 2;
$_SESSION['logged_in'] = true;


Now let's say there's a "Get User Profile" page, where you can select a
user's name and get their profile home page.

<a href="getprofile.php?userid=2">Nikolai</a>


If you were to click on this link, either the $_SESSION or the $_GET version
of 'userid' would be overwritten by the other, depending on the order which
the EGPCS variables are copied into $_REQUEST (and global scope, if
register_globals is on).


The first $_REQUEST['act'] in your CMS code is either $_GET['act'],
$_POST['act'], or $_SESSION['act'].  It's impossible to say.  My guess is
that it's $_GET.


does this clear things up?

nik

Message #3 by spam@k... on Fri, 20 Sep 2002 22:32:59 -0500
I wrote to the orignal programmer whose security class I now must use. He wrote this: 

>The way I've been using the "act" variable here isn't affected 
>by that
> matter, as there will always be only one action variable - 
>tells you what
> page to display. I've used REQUEST exactly because it also 
>catches a GET act
> or a POST one, so you wouldn't have to check if any of the two 
>is not null.

It occurs to me that his approach is a good one for updating code written before PHP 4.1 that assumes URL name/value pairs
automatically get turned into variables, code which might now encounter a site where the auto-globals thing is off. Yes? 

My content management system also relies on a dominant variable, $choiceMade, that is sometimes passed through the URL and sometimes
submitted as a form element. It seems unlikely to ever be overwritten by some other variable also called $choiceMade. So looking in
$_REQUEST rather than checking $_GET, $_POST, and $_SESSION seems like a time saver, with little risk. Yes?  






------------------------------------------------
On Tue, 17 Sep 2002 08:44:07 -0700, "Nikolai Devereaux" <yomama@u...> wrote:

> 
> $_REQUEST is a strange variable... it basically gives you the inconvenience
> associated with register_globals = off, but still has one major drawback --
> if you have two different superglobals with the same index defined, one of
> them will overwrite the other.
> 
> For instance, let's say you store the current logged in user's info in a
> session variable (as many people do).
> 
> // these are dummy values for the purpose of example:
> $_SESSION['userid'] = 4;
> $_SESSION['access'] = 2;
> $_SESSION['logged_in'] = true;
> 
> 
> Now let's say there's a "Get User Profile" page, where you can select a
> user's name and get their profile home page.
> 
> <a href="getprofile.php?userid=2">Nikolai</a>
> 
> 
> If you were to click on this link, either the $_SESSION or the $_GET version
> of 'userid' would be overwritten by the other, depending on the order which
> the EGPCS variables are copied into $_REQUEST (and global scope, if
> register_globals is on).
> 
> 
> The first $_REQUEST['act'] in your CMS code is either $_GET['act'],
> $_POST['act'], or $_SESSION['act'].  It's impossible to say.  My guess is
> that it's $_GET.
> 
> 
> does this clear things up?
> 
> nik
> 
> 
> 
Message #4 by "Nikolai Devereaux" <yomama@u...> on Mon, 23 Sep 2002 11:35:28 -0700
> It occurs to me that his approach is a good one for updating code
> written before PHP 4.1 that assumes URL name/value pairs
> automatically get turned into variables, code which might now
> encounter a site where the auto-globals thing is off. Yes?

Yeah, I suppose so.

> My content management system also relies on a dominant variable,
> $choiceMade, that is sometimes passed through the URL and sometimes
> submitted as a form element. It seems unlikely to ever be
> overwritten by some other variable also called $choiceMade. So
> looking in $_REQUEST rather than checking $_GET, $_POST, and
> $_SESSION seems like a time saver, with little risk. Yes?

It's really up to you, I guess.  If there's a variable that you're passing
around in links and forms (i.e. GET and POST, respectively), merely for the
purpose of persisting the name and value of that variable, then you should just
store it in a session var.

If you're passing the same named variable across links and forms (again, GET
and POST), then perhaps more strict design decisions need to be made.  When you
write your scripts to accept input data from anywhere, be it session, env, get,
and/or post, then you open yourself to sloppiness and potential error.  If you
write a page that sets "choiceMade" via a link, it's always best to check
$_GET, rather than $_REQUEST, to see if that value was set.

Once you start using _REQUEST, you commit yourself to always having the same
EGCPS order of insertion for ALL installations of PHP on ALL servers that might
run your code.  You will eventually find yourself in a situation where the
choiceMade from your _SESSION always overwrites the choiceMade the user
selected in a link or form post, and the site breaks.

The final decision always falls back on the developer.

Writing code is kind of like building bridges or twisty mountain roads --
they'd all look a lot prettier if it weren't for all the safety checks and
warning signs, but they'd be much more dangerous to use without them.


Nik


  Return to Index