Daniel Brown schreef:
On Mon, Jul 7, 2008 at 2:47 PM, mike <mike503@xxxxxxxxx> wrote:
I don't see why if you -know- you need $_COOKIE['username'] someone
would be lazy and use $_REQUEST['username']
That's the point --- it's intended as a fallback where you *don't*
know the method that will be used, or if you want to be lackadaisical
with your code (which, as we all know, is HIGHLY unrecommended).
So if you are an application service provider (ASP) who, perhaps,
runs a simple word shuffling script, with no database, email, or other
externally-processed services, you may have a script like so:
<?php
$word = $_REQUEST['word'];
echo str_shuffle($word)."<br />\n";
?>
Because, in this case, it really doesn't matter if $word is
obtained via GET or POST, so you can allow external users to use your
service via an HTTP POST form or a plain URL.
Conversely, it can also be used as a login mechanism or other
secure system, if you know what you're doing with regard to EGPCS
the C allow DoS attacks on clients via XXS/etc if $_REQUEST is used.
imagine setting a cookie "id=CANT_USE_THIS_SITE_ANYMORE" for a webshop
that has urls like "article.php?id=123" where article.php uses something like:
$id = (int)$_REQUEST["id"];
$_REQUEST is borked and should not contain ECS (of EGPCS) ... at least one
should be able to exclude certain superglobals without actually making not
set at all, currently you can't do that .. last I looked.
$_REQUEST = array_merge($_GET, $_POST); // the only sensible thing to do in all cases.
(which I mentioned to the wrong poster before! :-\) and proper secure
coding techniques. It will go through a matter of precedence, which
can be useful in some (rare) circumstances.
but still borked in the case of REQUEST, Stefan Esser wrote about it.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
