lecture d'une variable

comment faire pour lire une variable du genre
$mavariable="id";
echo $_GET['".$mavariable."'];

echo $_GET[$mavariable];

--
Astuces pour webmasters: http://www.crazycat.info
Tchat francophone: http://www.crazy-irc.net

CrazyCat <crazycat@nospam.c-p-f.org> écrivait :

comment faire pour lire une variable du genre
$mavariable="id";
echo $_GET['".$mavariable."'];

echo $_GET[$mavariable];

Les variables dynamiques du style $_GET[$ma_var] ou $_POST[$ma_var] ne
fonctionnent pas à l'intérieur d'une fonction.
Il faut alors utiliser $_REQUEST[$ma_var]

Par exemple :
function retourne_para($nom,$defaut) {
if (isset($_REQUEST[$nom])) return $_REQUEST[$nom];
else return $defaut;
}
--
Ce n'est pas parce que l'erreur se propage qu'elle devient vérité. Gandhi
Technologie aéronautique : http://aviatechno.free.fr (http://ottello.net)
Concorde dans la presse de 1965 à 2003 : http://le.pointu.free.fr

salut

Les variables dynamiques du style $_GET[$ma_var] ou $_POST[$ma_var] ne
fonctionnent pas à l'intérieur d'une fonction.
Il faut alors utiliser $_REQUEST[$ma_var]
$_GET, $_POST, tout comme $_REQUEST ou encore $_COOKIE sont des

variables superglobales et sont TOUTES accessibles dans les fonctions.

Fab

CrazyCat <crazycat@nospam.c-p-f.org> écrivait :

comment faire pour lire une variable du genre
$mavariable="id";
echo $_GET['".$mavariable."'];

echo $_GET[$mavariable];

Les variables dynamiques du style $_GET[$ma_var] ou $_POST[$ma_var] ne
fonctionnent pas à l'intérieur d'une fonction.

Pardon ?

# truc.php
<?php

function truc($name) {
if (isset($_GET[$name])) {
echo "$_GET[$name] == $_GET[$name]n";
}
else {
echo "oops ?";
}
}

truc("truc");
?>

http://localhost/~bruno/truc.php?truc=bidule

=>

$_GET[truc] == bidule

Il faut alors utiliser $_REQUEST[$ma_var]

Par exemple :
function retourne_para($nom,$defaut) {
if (isset($_REQUEST[$nom])) return $_REQUEST[$nom];
else return $defaut;
}

N'importe quoi. Tu ferais mieux de Lire le Fameux Manuel au lieu de
poster des âneries.

Bonjour,

Par exemple :
function retourne_para($nom,$defaut) {
if (isset($_REQUEST[$nom])) return $_REQUEST[$nom];
else return $defaut;
}

C'est bien de faire de l'adaptation des cours que je diffuse, mais encore
faudrait-il lire la page 18 avant la page 19.

<CITE>
Si pour une raison quelconque on souhaite se restreindre aux arguments
reçus par méthode GET, on peut utiliser le tableau prédéfini $_GET à la
place de $_REQUEST, ou le tableau $_POST pour se limiter aux arguments
reçus par méthode POST.
</CITE>

Si j'utilise $_REQUEST dans ce genre de chose, c'est uniquement pour
rendre tranparent le mode de transmission de la variable. Ce qui est débat
en soi mais un autre.

a++;
JG

echo $_GET['".$mavariable."'];
je ne sais pas pourquoi ne marche pas !

Outre les réponses déjà faites donnant la syntaxe à utiliser : c'est la
base de la gestion des strings en PHP. Tout ce qui est entre ' n'est pas
interprêté. Donc ici, on recherche dans $_GET une clef qui s'appelerait
".$mavariable." (avec les ", les . et le $ dans le nom de la clef).

Le piège inverse courant avec au contraire les " :

$path="C:abctoto"; // et paf! C:abc oto
car t c'est une tabulation.

HTH
a++;
JG

CrazyCat wrote:

comment faire pour lire une variable du genre
$mavariable="id";
echo $_GET['".$mavariable."'];

echo $_GET[$mavariable];

Bonjour Monsieur

C'est bon à savoir, ça va me servir pour mon package d'administration
de sondages, que je suis en train de concocter ( amoureusement, celà va
sans dire... )

En effet, je ne peux pas prévoir exactement le nombre de variables
$_POST[] qui vont être transmises en paramètres à mon script principal
d'administration, mais je peux prévoir une suite de variables de la
forme: $_POST['var_1'] , $_POST['var_2'] etc...

Donc, il me suffit de lire progressivement les variables var_$indice
avec $indice croissant à partir de 1, et d'arrêter quand la valeur
retournée n'existe pas.

Excellent.

J'envisage, pour la clarté du code, une séparation en fonctions,
chacune prenant en charge une fonctionnalité particulière, et demandant
une entrée de l'utilisateur ( souris ou clavier, un formulaire POST quoi ).

Au moment de l'envoi du formulaire de chaque fonction, le même script
est appelé avec une variable indiquant quelle prochaine fonction il
faudra appeler à partir du script. Donc les liens d'exécution entre les
fonctions sont fixés dans chaque fonction précédente.

Enfin, chaque fonction est appelée à partir du script où elle figure,
son interface écran ( mettons web ) s'affiche, et elle s'exécute
jusqu'au retour vers le script appelant, puis jusqu'à la fin du script
appelant.

C'est un paradigme que je n'ose appeler objet, puisqu'il n'y a pas
d'héritage ni de polymorphisme, par contre la structure des appels aux
fonctions peut très bien être un graphe, et non pas seulement une
arborescence, comme c'est le cas en programmation séquentielle classique.

Bien à vous.
Amicalement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Bonjour,

En effet, je ne peux pas prévoir exactement le nombre de variables
$_POST[] qui vont être transmises en paramètres à mon script principal
d'administration,

Si, si : il suffit de le passer en paramètre... Et si on une incohérence
entre ce nombre éclarer et celles présentes, on sort.
C'est exactement pour faire ce genre de trucs que le paragraphe
http://faqfclphp.free.fr/#rub2.15 a été écrit, à une époque où par défaut
register_globals était à On et donc on récupérait directement les
variables de nom dynamique depuis l'extérieur.

Au moment de l'envoi du formulaire de chaque fonction, le même script
est appelé avec une variable indiquant quelle prochaine fonction il
faudra appeler à partir du script. Donc les liens d'exécution entre les
fonctions sont fixés dans chaque fonction précédente.

Si j'ai bien compris, c'est le principe du hub : au lieu d'avoir
action1.php et action2.php on a $action qui arrive sur index.php et on
fait un switch dessus.

Dans tous les cas, meme si c'est un script d'admin, attention à bien
valider l'action courante à exécutée, car ele arrive du navigateur.

a++
JG

John GALLET wrote:

Bonjour,

Si, si : il suffit de le passer en paramètre... Et si on une incohérence
entre ce nombre éclarer et celles présentes, on sort.

Merci beaucoup Monsieur

Comme d'habitude, les fautes d'inattention dans la conception, c'est
mortel...

C'est vrai que votre solution est aussi plus sécurisée que la mienne,
qui est il est vrai sécurité minimum.

Si j'ai bien compris, c'est le principe du hub : au lieu d'avoir
action1.php et action2.php on a $action qui arrive sur index.php et on
fait un switch dessus.

Dans tous les cas, meme si c'est un script d'admin, attention à bien
valider l'action courante à exécutée, car ele arrive du navigateur.

Oh, ben...

Je vais simplement passer un indice numérique pour l'accès aux
fonctions *et* faire une vérification par identificateur de session, genre:

Si appel au script sans identificateur de session == celui enregistré
dans la base de données => ouverture nouvelle session avec
identificateur numérique = qqchose genre: md5sum(microtime()), puis
appel de la fonction donnant le menu principal d'administration.

Si appel au script avec identificateur de session == l'un de ceux
enregistrés dans la base, alors exécution normale.

Evidemment suppression à chaque entrée, des sessions durant depuis
longtemps ( manière classique, une seule requête SQL ).

L'accès au script est évidemment protégé par login/password avec
fichier .htaccess et .htpasswd de façon classique.

Pour l'affichage public du sondage choisi sur le site web ( une
fonction du package dans un autre script ), la prise en compte de
l'adresse IP pour l'unicité du sondage, ne se fera qu'à partir de la
prise en compte des données entrées par l'utilisateur, après l'appel au
deuxième script ( autre script ), et donnera lieu au même message de
remerciements, que les données soient ou non prises en compte ( adresse
IP client déjà dans la base => non prise en compte des données +
affichage de ce message. )

Je sais bien que l'adresse IP n'est pas suffisante pour les
authentifications, mais je sais que pour ma part, j'efface
systématiquement les cookies de mon navigateur à chaque fois que je
l'arrête, donc rien n'empêchant n'importe qui de faire de même s'il veut
voter plusieurs fois, je préfère ne tenir compte que de l'adresse IP.

La vérification par identificateur de session aléatoire pour le
script d'admin, me paraît fiable théoriquement, qu'en pensez-vous ?

Evidemment, si les cookies ne sont pas permis par le navigateur
client, l'id de session sera transmis par mes soins, en paramètre POST,
ce qui est faisable dans les même conditions qu'en GET. Il ne me semble
pas que l'on puisse usurper une session avec un autre navigateur
différent, à moins de conditions très très particulières, qu'il me
semble inutile de prévoir pour une telle utilisation ( fonctionnement
et sécurité du script d'admin des sondages. )

Merci de me donner votre avis sur le degré de sécurité,
particulièrement pour l'unicité des sondages par prise en compte de
l'adresse IP.

Je sais que dans votre site, vous dites bien qu'il est strictement
impossible d'authentifier des accès HTTP, mais bon, je ne cherche pas le
degré de fiabilité maximum...

Bien à vous.
Respectueusement.

Jean-François Ortolo

--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com

Re,

Comme d'habitude, les fautes d'inattention dans la conception, c'est
mortel...

Ca arrive à tout le monde. Le plus compliqué, c'est de faire simple.

C'est vrai que votre solution est aussi plus sécurisée que la mienne,
qui est il est vrai sécurité minimum.

Absolument pas, passer le nombre de variables permet juste de ne pas
s'emmerder pour écrire la boucle qui les récupère. Ni plus ni moins de
sécurité là dedans, c'est seulement plus facile à écrire. Dans les deux
cas, il faut ensuite vérifier si on a toutes les variables.

Si appel au script sans identificateur de session == celui enregistré
dans la base de données => ouverture nouvelle session avec
identificateur numérique = qqchose genre: md5sum(microtime()), puis
appel de la fonction donnant le menu principal d'administration.

Je n'ai pas compris la première ligne : pourquoi donne-t-on un accès quand
on compare une donnée NON RECUE avec une donnée en base ? Le "sans" doit
être une faute de frappe.

Si appel au script avec identificateur de session == l'un de ceux
enregistrés dans la base, alors exécution normale.
Ah bah non, c'était volontaire. Donc je n'ai pas compris la logique

d'attribution du token.

L'accès au script est évidemment protégé par login/password avec
fichier .htaccess et .htpasswd de façon classique.

"Houba, houba, hop !" (c) Marsupilami Franquini. On a plusieurs
utilisateurs avec des sessions (celle de ci-dessus) différentes ou un seul
luser ?

La vérification par identificateur de session aléatoire pour le
script d'admin, me paraît fiable théoriquement, qu'en pensez-vous ?

cf http://www.saphirtech.com/cours_php.html chapitre sessions.

Merci de me donner votre avis sur le degré de sécurité,
particulièrement pour l'unicité des sondages par prise en compte de
l'adresse IP.

Il n'y a aucune solution fiable concernant les sondages. Vous aviez déjà
eut strictement le même problème sur l'accès aux stats restreintes si ma
mémoire est bonne. L'alternative est l'adresse email, qui permet tout
autant de truander le système si on le souhaite mais ne poubellise pas des
votes légitimes.

En étant bien conscient que ceci retirera des votes normaux, pour ce
besoin, l'IP est une solution acceptable. On pourrait avoir un système de
time out de quelques heures/jours pour la liste des "ip votantes".

Je sais que dans votre site, vous dites bien qu'il est strictement
impossible d'authentifier des accès HTTP, mais bon, je ne cherche pas le
degré de fiabilité maximum...

Pour un système de sondage anonyme, je n'en connais pas qui soit
incontournable par un truandeur. On peut juste lui rendre la vie pénible.

On peut aussi de manière classique ajouter la demande de saisie d'une
suite de lettres/chiffres affichés par la GD lib, non pas tellement pour
éviter les scripts, mais surtout ici pour que le truandeur se lasse. La
liste des séquences valides affichées est conservée côté serveur, on tente
un DELETE et si affected_rows==1 c'est qu'elle était valide d'une part
(donc on peut la compter dans les stats) et tout refresh échouera.

Respectueusement.
aïe mes chevilles !

JG