2009-02-07 7 views
0

Je me souviens avoir revu le code PHP d'une autre personne et il avait une fonction ou une méthode de classe qui roulait toutes les variables GET et POST dans un seul objet ancien qui pouvait alors être passé. Si la même paire nom-valeur apparaissait à la fois dans GET et POST, POST gagnerait.Fonction php pour assembler des variables externes en un seul objet sans tenir compte de GET ou POST

Existe-t-il un add-on PHP bien codé de toute sorte qui fait exactement cela?

Répondre

7

Vous pouvez utiliser $_REQUEST, mais sachez qu'il contient le contenu de $_GET, $_POST et $_COOKIE, et que la présence (et l'ordre, pour écraser fins) des variables dans cette superglobale est soumise à la configuration dans l'environnement d'exécution.

Si c'est à l'origine des problèmes, il pourrait être une bonne idée de rouler une version simple, le nœud qui serait quelque chose comme

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

Vous pouvez ensuite envelopper cela dans une certaine façon, peut-être fournir fonctionnalité utile supplémentaire, par exemple appliquer automatiquement stripslashes() aux valeurs à l'aide magic_quotes déchiquetés, fournissant des valeurs par défaut des variables manquantes, etc.

0

vous pouvez utiliser la variable globale $ _REQUEST. il est défini par le PHP interprété par défaut lorsque votre application s'exécute dans web sapi (comme CGI ou module serveur web) ce qui est le cas de votre application lorsque vous écrivez des applications web en PHP. $ _REQUEST est un tableau associatif de toutes les données dans $ _GET et $ _POST et est défini par défaut. aucune extension/librari n'est nécessaire pour l'utiliser.

+0

Par défaut, $ _REQUEST contient également des données de cookie et est sujet à un réapprovisionnement imprévisible en fonction de la configuration. – Rob

1

je considérer une mauvaise pratique amalgamer $_GET avec $_POST. Ils sont destinés à des choses complètement différentes, et en les traitant comme égaux, vous utilisez abusivement le protocole HTTP. Comme mentionné, $_REQUEST fait ce que vous voulez, mais est un peu imprévisible. Vous pouvez facilement écrire votre propre fonction globale pour faire la même chose:

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

Mais vraiment ... c'est une mauvaise pratique.

+0

Je suis d'accord - une requête GET ne devrait pas avoir d'effets secondaires, alors qu'une requête POST peut mettre à jour ou supprimer des données, etc. La stratégie d'OP efface cette distinction. Cela pourrait signifier que, par exemple, un web spider vérifiant les liens sur un site pourrait supprimer certaines données. –

0

Ceci est la classe de mon framework qui gère les globals dans toute l'application. Aucun traitement des variables n'est fait ici.

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; 
} 

}

Pour l'utiliser partout

$myObj = stGlobal::getInstance(); 
2

La fusion des deux variables (ou en utilisant à la place $_REQUEST ou Register Globals) peut provoquer des failles de sécurité que vous ne pouvez pas definetly identifier la source de ses valeurs. Donc, lorsque vous accédez à $_REQUEST['foobar'], vous ne pouvez pas dire si la valeur a été envoyée via URL, corps POST ou Cookie. Cela peut rendre votre script vulnérable pour Cross-Site Request Forgery.

Je vous recommande donc d'opter pour la sécurité au détriment du confort et d'utiliser les variables dont vous attendez vos valeurs. $_GET pour les arguments qui sont censés être transmis par URL, $_POST pour ceux passés via POST et $_COOKIE pour les cookies.

+0

Cross Site Request Les failles de forgeage ne sont un problème que si l'application place différents niveaux de confiance dans les différents vecteurs d'entrée utilisateur. Pour une sécurité maximale, * tous * les vecteurs d'entrée utilisateur doivent être considérés comme intrinsèquement indignes de confiance. Compte tenu de ce fait, on pourrait soutenir que la fusion des variables est en fait * plus * sûre car elle efface l'hypothèse injustifiable d'un seul vecteur d'entrée d'utilisateur digne de confiance. – dreftymac

Questions connexes