Whats the purpose of it? I know it does $_POST, $_GET, and $_COOKIE, but what exactly is the purpose of it?

__________________
VillageIdiot can have my babbies ;d

$_REQUEST contains all the data in $_GET, $_POST and $_COOKIES.

If you use $_REQUEST to check if some data was passed to your page you don't know if this data is coming from the URL (script.php?variable=value), if it was posted from a form or if it was stored in a cookie.

Let's say you store the username in a cookie and then use it to print the username in every page.
Since you're using $_REQUEST, I can trick your page into displaying whatever I want just by typing page.php?user=SomeUser in the browser address bar.

$_REQUEST just meshes them all together, leaving a name clash problem. I did some tests on name clashes. In the event of a name clash, it will respond in this order (if above exists, it overrides below)
Cookies
POST
GET

Therefore if you mean to get $_POST["user"] but $_COOKIE["user"] exists, you will have a mismatch. That could be an error, but if exploited right, a security risk. Don't use $_REQUEST

Now to answer your question: What is its purpose. I guess it could have uses if you dont know where the variable will exist, but I dont see it as worth the possible security risk. Like the goto line in BASIC languages, it has some specific uses but its bad outweighs the good. Not a great comparison because GOTO is pure, sadistic evil, but its the best I could think of off the top of my head.

__________________

This is one big security flaw to me :P, vBulletin uses almost all $_REQUEST, so what could they have, and ironic that this forum uses vb.

__________________
VillageIdiot can have my babbies ;d

VB has messy code, but I bet they just purposefully stay from name clashes.

__________________

Village Idiot, I invite you to explain how using $_REQUEST presents a possible security risk above and beyond anything already available for $_GET/POST/COOKIE individually. It's all well and good saying "if exploited right, a security risk" but how are folks to learn if they're told how that risk is put into place and why?

To change the order in which the variables are parsed into $_REQUEST, you can use the variables_order (manual) php.ini directive which is "EGPCS" by default meaning that the order is ENVIRONMENT, GET, POST, COOKIE then finally SERVER. For the sake of $_REQUEST, if both $_GET['action'] and $_POST['action'] exist, then $_REQUEST['action'] will be given the value of whatever comes last in the variables_order list (so, POST by default). Note: ENV and SERVER values aren't mushed into the REQUEST superglobal variable, just GET/POST/COOKIE.

I can't remember the last time that I used $_REQUEST in anything other than experimenting -- I've no reason in my everyday code to cater for one item of user input coming in from more than one place and if that were the case I'd likely want to know which place it came from anyway.

Exploitation to be a security risk would be really difficult, unless you have the source of the script. Here is a scenario that it could happen in.
You are passing an ID variable though POST, the script generated that number after authenticating the other stuff. Point is, the POST variable is secure. You go though the process and edit the row with that ID. All the user would have to do to edit another row is set a cookie with the same name and a different ID. $_REQUEST will process the value of the cookie.

Now this could be secured by passing all the user given vars though and processing them at the end. But like every potential security hole, even if its takes somewhat flawed (but still functional) design to work, don't use it.

__________________

Although $_REQUEST sounds yummy :) it has its downsides. Big downsides as described in this thread.
Nowdays everything is crawling with script kiddies and XSS maniacs - just remember the whole story with phpBB about two years ago when they were having major security issues.
Well, let's get back to the real thing.
If you are using POST or GET or any other method - access it trough its "interface" ( $_POST, $_GET etc).
Another thing you could do - is wrap your superglobals.
I was searching for that kind of wrapper and I've found Inspekt - just wrap your superglobals and you are a bit more protected using them - especially the $_GET superglobal. Why?
Well, majority of XSS attacks come trough that specific superglobal - SQL Injections, JS injections etc. If you are using $_GET['id'] just for passing IDs from your table - why not attach a checking system to it, as you would probably do for your forms (text field - only numeric, max 4 chars - for example).

Maybe I was a bit offtopic but I've written everything that comes to mind about superglobals.
Cheers! :D

__________________
Back from sysadmins to the programmers.

Recently there was a long debate on a local PHP mailing list which I'm subscribed to. The only argument that was valid against using $_REQUEST was the variables getting over written. Exploits using $_REQUEST can be done just as easily through $_GET, $_POST, or $_COOKIE. Sanitize your data and run your checks.

VB, phpBB and probably a lot more large scripts use $_REQUEST.

You could write a script that submits the data as POST. Cookie or not it doesn't really matter. You should be checking to see if the person actually has the ability to do the action before doing the action. You don't have to use the forms within the program to submit data.

That has nothing to do with $_REQUEST though.

__________________
Eric

Welcome to mmoggg website to buy RS Gold, offer a lot, of course, Diablo 3 Gold and Cheap RS Gold, to be purchased at any time, at any time shipment, and Diablo 3 Gold Kaufen look forward to your visit!