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.
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 ;-) !
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.
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";
}
?>
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...
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).
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 !
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.
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.
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...)
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)
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.
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 !).
27 sept. 2005 à 15:46
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."
27 sept. 2005 à 15:40
27 sept. 2005 à 15:20
27 sept. 2005 à 13:21
27 sept. 2005 à 13:08
27 sept. 2005 à 13:00
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 ;-) !
27 sept. 2005 à 12:54
c'est une superglobale, tu peux utiliser $_REQUEST avec les register à off :-)
27 sept. 2005 à 11:29
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.
27 sept. 2005 à 11:10
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";
}
?>
27 sept. 2005 à 11:04
Donc, j'ai appris un truc :-) Je m'en fous parce que je n'utilise jamais $_REQUEST, mais bon...
27 sept. 2005 à 10:50
27 sept. 2005 à 10:40
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
}
?>
27 sept. 2005 à 10:33
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).
27 sept. 2005 à 10:12
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 !
27 sept. 2005 à 09:50
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.
12 sept. 2005 à 19:11
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...
10 sept. 2005 à 20:42
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
9 sept. 2005 à 17:48
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...)
9 sept. 2005 à 14:49
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)
9 sept. 2005 à 09:15
9 sept. 2005 à 09:15
# 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.
9 sept. 2005 à 08:45
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 !).
9 sept. 2005 à 03:35
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)
8 sept. 2005 à 22:49
# {
# $value = ( isset($HTTP_GET_VARS[$name]) ) ? $HTTP_GET_VARS[$name] : $HTTP_POST_VARS[$name];"
Arf, 2 fois le même test... !