views:

474

answers:

5

Question: I recall reviewing someone else's PHP code once and he had a function or class method that rolled all GET and POST variables into a single plain old object that could then be passed around. If the same name-value pair appeared in both GET and POST, POST would win.

Is there a well-coded PHP add-on out there of any sort that does exactly this?

A: 

you can use $_REQUEST global variable. it is defined by the PHP interpreted by default when your application is running in web sapi (like CGI or web server module) which is the case of your application when you are writing web based applications using PHP. $_REQUEST is an associative array of all data in $_GET and $_POST and is defined by default. no extension/librari is needed to use it.

farzad
By default, $_REQUEST contains cookie data as well, and is subject to unpredictable re-ordering based on configuration.
Rob
+8  A: 

You could use $_REQUEST, but be aware that it contains the contents of $_GET, $_POST and $_COOKIE, and that the presence (and order, for overwriting purposes) of variables in this superglobal is subject to configuration in the execution environment.

If this is causing problems, it might be a good idea to roll up a simple version, the crux of which would be something like

$requestData = array_merge( $_GET, $_POST );

You can then wrap this up in some fashion, perhaps providing additional useful functionality, e.g. automatically applying stripslashes() to values mangled using magic_quotes, providing default values for missing variables, etc.

Rob
+1  A: 

I'd consider it bad practise to conflate $_GET with $_POST. They are meant for completely different things, and by treating them as equal, you are effectively misusing the HTTP protocol. As mentioned, $_REQUEST does what you want, but is a little unpredictable. You could easily write your own global function to do the same:

function param($name, $default = null) {
  return isset($_POST[$name])
    ? $_POST[$name]
    : (isset($_GET[$name])
      ? $_GET[$name] 
      : $default);
}

But really .. it's bad practise.

troelskn
I agree - a GET request should not have side effects, whereas a POST request may update or delete data, etc. OP's strategy erases that distinction. This could mean that, for example, a web spider checking out the links on a site could delete some data.
Nathan Long
A: 

This is the class from my framework that handles globals throughout the app. No processing of the variables is done here.

class stGlobal

{

//instance
private static $instance;

//global settings
public $post = '';
public $get = '';
public $files = '';
public $request = '';

private function initialize()
{
 $this->post = $_POST;
 $this->get = $_GET;
 $this->files = $_FILES;
 $this->request = $_REQUEST;
}

public function getInstance()
{
 if (!isset(self::$instance))
 {
  $class = __CLASS__;
  self::$instance = new $class();
  self::$instance->initialize();
 }
 return self::$instance;
}

}

To use it anywhere

$myObj = stGlobal::getInstance();
Syntax
+1  A: 

Merging both variables (or using $_REQUEST or Register Globals instead) can cause security flaws as you cannot definetly identify the source of its values. So when accessing $_REQUEST['foobar'] you cannot tell if the value has been sent via URL, POST body or Cookie. This can make you script vulnerable for Cross-Site Request Forgery.

So I recommend you to go for security over comfort and use those variables where you expect your values come from. $_GET for arguments that are expected to be passed by URL, $_POST for those passed via POST and $_COOKIE for cookies.

Gumbo
Cross Site Request Forgery vulnerabilities are only an issue if the application places varying levels of trust in the different user input vectors. For maximum security, *all* user input vectors should be considered inherently untrustworthy. Given this fact, it could be argued that merging the variables is actually *more* secure because it erases the unjustifiable assumption of any single trustworthy user input vector.
dreftymac