CLASSE DE GESTION DE REQUÊTE

FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
- 8 sept. 2005 à 22:49
J_G
Messages postés
1406
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
28 août 2007
- 27 sept. 2005 à 15:46
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/33708-classe-de-gestion-de-requete

J_G
Messages postés
1406
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
28 août 2007
9
27 sept. 2005 à 15:46
Merci de te manifester...
C'est quand plus sympas quand la censure est expliquée

"J'approuve la charte de bonne conduite que je viens de lire ci-dessous."
cs_Arnotic
Messages postés
933
Date d'inscription
dimanche 1 avril 2001
Statut
Membre
Dernière intervention
9 janvier 2012
1
27 sept. 2005 à 15:40
Parler de l'avenir de PHP, pas de soucis. Faire des réflexion déplacées a propos de CodeS-SourceS, ASP, Microsoft ou autre, c'est non.
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
9
27 sept. 2005 à 15:20
c'est ça le problème, autant tout clarifier dès le début comme ça ça évite les erreurs que nous voyons souvent :-)
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
27 sept. 2005 à 13:21
Oui...c'est marrant quand même : php a commencé comme un langage très (rtop...) permissif, mais il y avait une raison : c'est un langage de script (même côté serveur), il se devait d'être simple. Et puis au fil du temps, il se complexifie, et devient nettement plus exigeant en rigueur...curieux comme choix.
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
9
27 sept. 2005 à 13:08
tant mieux que PHP5 ne permette plus ça :-)
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
27 sept. 2005 à 13:00
Ok, de toutes façons visiblement, en php5, on ne peut plus du tout, lol.

ET puis de toutes façons, je ne vois pas pourquoi je me suis lancé là-dedans puisque je viens d'un coup de réaliser que register_globals n'a aucun rapport avec ça...lol...ça permet juste de ne pas utiliser directement les index des superglobales en tant que variables...suis lourd des fois ;-) !
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
9
27 sept. 2005 à 12:54
"$_REQUEST ne doit pouvoir s'utiliser qu'avec les register_globals à on, justement. Mais je n'en suis pas sûr."

c'est une superglobale, tu peux utiliser $_REQUEST avec les register à off :-)
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
27 sept. 2005 à 11:29
J'ai pas dit que register_globals devait être à on. Lol. Le mien est à off depuis très longtemps. De même que register_long_arrays d'ailleurs.
Ce que je disais c'est que $_REQUEST ne doit pouvoir s'utiliser qu'avec les register_globals à on, justement. Mais je n'en suis pas sûr.
J_G
Messages postés
1406
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
28 août 2007
9
27 sept. 2005 à 11:10
Non, cet exemple montre qu'en utilisat $_REQUEST tu passe à coté du contrôle de l'origine montré ci-dessus.

register_globals est une connerie !
Ca veut dire que $pouet = $_POST['pouet']; (par exmple)
Sans avoir besoin de l'écrire !

un petit exemple du danger de register_globals ??? Aller hop !

Exemple 29-1. Exemple de mésutilisation de register_globals = on

<?php
// $authorized = true uniquement si l'utilisateur est identifié
if (authenticated_user()) {
$authorized = true;
}

// Comme nous n'avons pas initialisé $authorized avec false, cette dernière
// peut être définie via register_globals, comme avec l'URL GET auth.php?authorized=1
// Tout le monde peut facilement être reconnu comme identifié!
if ($authorized) {
include "/donnees/critiques/data.php";
}
?>
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
27 sept. 2005 à 11:04
Bon ben après vérification il semble que tu aies raison. Aucun mooyen de récupérer une variable dans $_GET dans le tableau $_REQUEST, avec mon php5, même en triturant php.ini

Donc, j'ai appris un truc :-) Je m'en fous parce que je n'utilise jamais $_REQUEST, mais bon...
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
27 sept. 2005 à 10:50
Oui mais ça, c'est parce que register_globals est à off. Si tu le mets à on, tu peux utiliser $_REQUEST (à priori hein).
J_G
Messages postés
1406
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
28 août 2007
9
27 sept. 2005 à 10:40
Merci malalam,

Pour compléter mes dire, un extrait de la doc:


Exemple 29-3. Détection simple de fausses variables
<?php
if (isset($_COOKIE['MAGIC_COOKIE'])) {

// MAGIC_COOKIE provient d'un cookie.
// Assurez-vous de valider les données du cookie!

} elseif (isset($_GET['MAGIC_COOKIE']) || isset($_POST['MAGIC_COOKIE'])) {

mail("admin@example.com", "Tentative possible d'attaque", $_SERVER['REMOTE_ADDR']);
echo "Alerte sécurité, l'admin a été prévenu.";
exit;

} else {

// MAGIC_COOKIE ne provient pas de REQUEST

}
?>
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
27 sept. 2005 à 10:33
Hello,

pour $_REQUEST, Antho je ne sais pas, mais moi, j'infirme.
$_REQUEST est toujours valable.
Sauf qu'il semble (jamais essayé) qu'on puisse la désactiver avec register_long_arrays (ainsi que les vieux http_post_vars et compagnie).
J_G
Messages postés
1406
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
28 août 2007
9
27 sept. 2005 à 10:12
Salut tsous le monde,
Salut Ricou,

D'abord, tu as 15 fois raison : $_REQUEST existe, est un "merge" de $_POST, $_GET et $_COOKIE et est super-global...

Mais il ne faut pas utiliser ce raccourci infâme, qui d'ailleur n'existe plus en PHP5 (j'ai cru lire ça dans un bouquin.. Antho : confirmes-tu ?).

Bref, qu'il existe ou pas, le problème est que avec $_REQUEST tu ne contrôles plus la provenance de tes variables...?

Si tu utilises un formulaire en post et que je soumet ce formulaire avec ?ID=pouet dans l'url et en envoyant un cookie ID=truc... Qu'est ce qui va se passer pour $_REQUEST['ID'] ?

Bon, rien de bien grave si tu blinde ton script autour. Mais il n'est pas la peine d'ajouter de la confusion dans la provenance des variables

(Par exemeple register_global est une plus grosse connerie dans le même genre)

Bon voila, tout ça pour dire que la source ci-dessus casse pas des briques... Et en plus elle ne fait pas de SQL !
cs_Ricou13
Messages postés
40
Date d'inscription
lundi 16 décembre 2002
Statut
Membre
Dernière intervention
8 septembre 2006

27 sept. 2005 à 09:50
Salut,

Encore une critique, désolé. Je n'ai pas noté.

Je ne vois qu'un seul intérêt aux fonctions "GetSessionVariable" et "SetSessionVariable" et, encore, je doute fortement que cela ait été ta motivation. C'est que, si un jour, par hasard, on ne sait jamais, la variable $_SESSION changeait de nom (comme $_HTTP_POST_VARS est devenue $_POST), cela simplifierait la mise à jour du site (bien que l'ancien nom devrait toujours rester actif :-? ) en ne faisant la modif qu'a un seul endroit.

Personne n'en a parlé (et je ne suis pas un pro du PHP) mais il me semble bien que l'on pourrait largement simplifier la fonction "GetRequestVariable" puisqu'elle récupère la variable demandée, qu'elle soit transmise par GET ou POST (je ne modifie pas du tout le sens de la fonction, ce n'est pas mon but) :

function GetRequestVariable($name)
{
global $_REQUEST;
if (isset($_REQUEST[$name])) return $_REQUEST[$name];
}

Et je ne suis pas certain que "global $_REQUEST;" serve à quelque chose puisqu'il me semble que $_REQUEST est une "superglobale" et qu'elle serait donc toujours accessible.
Donc écrire
$variable = GetRequestVariable('toto');

Revient au même (en plus lourd) que d'écrire directement
if (isset($_REQUEST['toto'])) $variable = $_REQUEST['toto'];

Sinon, je ne vois pas trop le rapport avec le titre "CLASSE DE GESTION DE REQUÊTE". Sur le coup, j'ai cru que c'était une classe pour gérer les requètes SQL :-(

J_G, quand tu écris "avec ça, je casse ton formulaire simplement en envoyant une variable dans l'url...", tu peux expliquer ? Parce que je ne vois pas trop ce que ça peut faire comme dégats.
J_G
Messages postés
1406
Date d'inscription
mercredi 17 août 2005
Statut
Membre
Dernière intervention
28 août 2007
9
12 sept. 2005 à 19:11
Salut,

Désolé, mais je vais encore ajouter un commentaire critique. Ne le prend pas mal, le but est de te montrer qques soucis.

Bon je comprend bien ce qui à motivé ta classe : la flème. C'est une raison si.. déraisonnable.

$value = ( isset($HTTP_GET_VARS[$name]) ) ? $HTTP_GET_VARS[$name] : $HTTP_POST_VARS[$name];

avec ça, je casse ton formulaire simplement en envoyant une variable dans l'url...

Bon puis est-ce vraiment utile d'utiliser une classe pour ça ? Des fonctions auraient largement suffies

2/10...
ashboody
Messages postés
91
Date d'inscription
samedi 30 mars 2002
Statut
Membre
Dernière intervention
11 octobre 2005

10 sept. 2005 à 20:42
mouai c vraiment creux comme code, pire que du .NET je dirais lol

l'utilisation d'une classe pour cela n'est pa approprié. Un core.php réalisant ceci à inclure dans l'entete de page aurait été plus approprié je pense.

bonne continuation
cs_Anthomicro
Messages postés
9433
Date d'inscription
mardi 9 octobre 2001
Statut
Membre
Dernière intervention
13 avril 2007
9
9 sept. 2005 à 17:48
Salut,

y'a plein de trucs redondants, dont la fonction pour retourner la valeur de la session, ça ralentit inutilement le script (ainsi que la fonction de redirection par exemple...)
Florynth
Messages postés
48
Date d'inscription
mardi 19 novembre 2002
Statut
Membre
Dernière intervention
7 février 2008

9 sept. 2005 à 14:49
Je vais essayé de défendre mon code un peu.

L'utilisation de ma classe est un fait dans un but de dévellopement d'un gestionnaire de site qui par la suite va être utilisé par un utilisateur externe qui ne modifiera pas le code en soi.

Donc par exemple si il y a des variables sessions auquel le webmaster n'a pas accès un validation supplémentaire devra être prêt programmé avant la réutilisation du code (bien entendu puisque le code est ouvert contrairement a un dll il pourrait allé modifier le tout mais l'idée et que le code doit être utilisé par quelqu'un qui n'est pas programmeur mais plutôt webmaster/designer)

Et oui en effet le code n'est pas en php 5 car le serveur ou je suis ne le supporte pas, mais je suis en train de changé de seveur alors je vais faire les modifications nécessaire d'ici quelques jour ;O)
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
9 sept. 2005 à 09:15
Pour ma part je mets 3, pour les raisons citées au-dessus.
malalam
Messages postés
10839
Date d'inscription
lundi 24 février 2003
Statut
Membre
Dernière intervention
2 mars 2010
25
9 sept. 2005 à 09:15
Et puis, au-delà de la programmation approximative, je ne vois pas l'intérêt de ce code. Notamment ces fonctions :

# function GetSessionVariable($name)
# {
# return $_SESSION['$name'];
# }
#
# function SetSessionVariable($name,$variable)
# {
# $_SESSION['$name'] = $variable;
# }
#
Pour moi ça revient à faire une fonction Hello World...

function helloWorld () {
echo 'Hello World';
}

Franchement, entre taper :

echo GetSessionVariable('pseudo');
et
echo $_SESSION['pseudo'];

...
Et je suis d'accord avec IsoThoP, ce code ne mérite pas une classe. attention, l'idée peut-être bonne...mais il faut largement rembourrer tout ça pour que ça devienne intéressant.
Isoth0p
Messages postés
42
Date d'inscription
jeudi 17 juin 2004
Statut
Membre
Dernière intervention
15 septembre 2005

9 sept. 2005 à 08:45
Il y a des erreurs dans le code :
return $_SESSION['$name'];
En effet les quotes simples vont chercher la session '$name' et non pas le nom de celle contenu dans $name.
return $_SESSION[ $name ];

Il me semble ensuite que le nombre entre crochets pour l'user-agent MSIE dépend de sa version. Auquel cas il est plus judicieux de se contenter de rechercher le motif 'MSIE'. Autre remarque, tu utilises ereg, or tu ne fais pas appel à une chaîne formattée POSIX, quel est donc l'interet ? Voici une solution alternative :
if ( strpos( $HTTP_USER_AGENT, 'MSIE' ) !== false ) ...

Il est plus propre d'utiliser $_GET et $_POST à la place de $HTTP_GET_VARS et $HTTP_POST_VARS.

Il vaut mieux effectuer un die après ton header Location.

N'utilise pas de double quotes et sort donc ta variable $now.

Je te mets 4/10. En effet le code n'est pas optimisé et contient des erreurs. De plus tu ne tires aucun profit de l'utilisation d'une classe (même pas en PHP5 qui plus est !).
Florynth
Messages postés
48
Date d'inscription
mardi 19 novembre 2002
Statut
Membre
Dernière intervention
7 février 2008

9 sept. 2005 à 03:35
Désolé ce n'est pas le même test ;O)

si tu lis comme il faut

le premier test vérifi si la valeur est bien existante

après elle renvoi la valeur qui est pris du bon header (soit GET ou POST)

si on met seulement le deuxième test et que la valeur n'est pas dans le GET elle n'est pas nécessaire dans le POST non plus :O)
FhX
Messages postés
2350
Date d'inscription
mercredi 13 octobre 2004
Statut
Membre
Dernière intervention
18 avril 2015
3
8 sept. 2005 à 22:49
"# if ( isset($HTTP_GET_VARS[$name]) || isset($HTTP_POST_VARS[$name]) )
# {
# $value = ( isset($HTTP_GET_VARS[$name]) ) ? $HTTP_GET_VARS[$name] : $HTTP_POST_VARS[$name];"
Arf, 2 fois le même test... !