Que de complications !! 
 De Mikael Chelli - Dimanche 16 Décembre 2001 à 01:35

Bravo pour ton article qui est très bien mais bon, il prend un peu la tête !! :-)
C pas un reproche, c'est juste de la fainéantise et que tu aurais du faire un pti résumé à la fin pour simplifier le tout :)

  Re: Que de complications !! 
 De J-Pierre Dézélus - Dimanche 16 Décembre 2001 à 10:06

C'est vrai qu'au début je ne pensais pas faire aussi long, mais finalement en l'écrivant je me suis dit qu'il valait mieux être le plus exhaustif possible.

C'est un tournant très important pour PHP, il faut que chacun en prenne conscience.

  Re: Que de complications !! 
 De Gérald ANDRE - Lundi 17 Décembre 2001 à 12:13

Salut, merci pour cet article.
Par contre, je ne vois pas en quoi la méthode utilisée pour PhpMyAdmin sécurise quoique ce soit.
Elle est utilisée pour faire tourner l'application avec register_globals=off, mais on peut toujours forcer les valeurs des variables. Il faudrait pour bien faire utiliser la fonction import_request_variables() (décrite dans ton article) pour ajouter un entête aux noms des variables.
Ou alors j'ai rien compris.

  Re: Que de complications !! 
 De J-Pierre Dézélus - Lundi 17 Décembre 2001 à 12:44

Je n'ai pas dit que la méthode utilisée par PhpMyAdmin sécurisait les scripts, mais simplement qu'ils priviligaient l'utilisation des variables $_* quand elles existent, puis celle des variables $HTTP_*_VARS.

  Re: Que de complications !! 
 De Gérald ANDRE - Lundi 17 Décembre 2001 à 16:58

OK. Par contre je me pose la question de ce qu'apporte ce système à la sécurisation du script que tu as donné en exemple.
Si j'écris :
if ($_POST['authentifie'])
{...}
cela ne change rien. Je peux toujours accéder à l'info.

  Re: Que de complications !! 
 De J-Pierre Dézélus - Lundi 17 Décembre 2001 à 17:13

Oui, sauf que tu ne le feras pas !!!
$authentifie est une variable locale à ton script, elle ne dépend des données utilisateur. Tu n'as aucune raison d'aller chercher $_GET ou $_POST.

  Re: Que de complications !! 
 De Gérald ANDRE - Lundi 17 Décembre 2001 à 17:40

>Oui, sauf que tu ne le feras pas !!!
>$authentifie est une variable locale à ton script, >elle ne dépend des données utilisateur. Tu n'as >aucune raison d'aller chercher $_GET ou $_POST.
OK je vois ce que tu veux dire. Merci. Mais le pb reste que tant que tous les serveurs n'ont pas le register à off, il va falloir trouver une autre méthode pour sécuriser le script :-(

  A propos de 'import_request_variables()' 
 De Jérôme FIX - Lundi 17 Décembre 2001 à 18:52

Je ne suis pas sur que l'utilisation de la fonction import_request_variables() soit réellement une bonne idée.
En effet, avec les tableaux $_GET,$_POST, ... on va avoir le double de variables en mémoire et toutes en double.

  Re: A propos de 'import_request_variables()' 
 De Gérald ANDRE - Mardi 18 Décembre 2001 à 12:03

J'espère que tu n'as pas 20ko de paramètres pour tes scripts !!! ;-)
De toute façon tu ne travailleras pas directement avec les tableaux dans tes algos. Tu vas mettre les variables dont tu as besoin dans des variables locales (les variables globales c'est pas beau dans le source).
En plus, avant que les serveurs passent en 4.1, ce n'est pas maintenant que l'on va commencer à utiliser cette fonction. Donc je retire ce que j'ai dit.

  import_request_variable 
 De Pierre-Alain Joye - Dimanche 16 Décembre 2001 à 01:46

A noter une nouvelle fonction tres pratique garantissant uniquement l'import des variables necessaires :import_request_variable.

A utiliser sous la forme suivante :
import_request_variable("G","getvars_");

Le 1er parametre etant le type de variables a importer G pour get P pour post et enfin C pour les cookies, les trois peuvent etre appele en meme temps. Le second parametre ajoutera un prefix au debut de chaque variable.

voili voilou

  Re: import_request_variable 
 De J-Pierre Dézélus - Dimanche 16 Décembre 2001 à 10:08

Oh toi tu n'as pas lu tout l'article ... ;o)

  Re: import_request_variable 
 De Pierre-Alain Joye - Dimanche 16 Décembre 2001 à 12:26

ooohhhh ben m'apprendra a lire en diagonale ;).

  Applications publiques ... 
 De Pierre Gentile - Dimanche 16 Décembre 2001 à 10:32

Pour des applications publiques, autant faire une fonction qui extrait ces variables.
On peut aussi faire évoluer la fonction en respectant les magic-quotes.
Je pense que je vais faire comme ça dans mes prochains dévellopements !
(et merci pour l'article, JP !)

  Et les sessions ? 
 De Valério Burgarello - Dimanche 16 Décembre 2001 à 13:26

Salut, j'ai appris pas mal de chose avec cet article, cependant j'ai toujours le même problème.

Lorsque je mets le register_global sur OFF, j'ai des problèmes avec les sessions.
Exemple :

<?
session_start();
$login=$_POST["login"];
$pass=$_POST["pass"];

session_register("login");
session_register("pass");

header("Location: index.php");
?>

Ca ne fonctionne pas du tout, et aussi comment je récupère les valeurs des sessions ?
$login=$_SESSION["login"]; ?

J'espère que vous éclaircisserez ma lanterne :)

Bonne journée :)

  Re: Et les sessions ? 
 De J-Pierre Dézélus - Dimanche 16 Décembre 2001 à 14:58

Attention les variables $_* ne sont pas disponibles sur les versions de PHP < 4.1.0.
Elles ne sont pas directement liées à la variable register_globals. Elles ont été aijoutées dans PHP 4.1.0 pour faciliter le passage de register_globals à Off.

PS: tu as des messages d'erreur ?

  Re: Et les sessions ? 
 De Valério Burgarello - Dimanche 16 Décembre 2001 à 15:31

Heu... fausse alerte, le code que j'ai fait fonctionne correctement :)
Désolé du dérangement

PS : j'avais mal configuré le path pour les sessions :)

  Error Reporting ? 
 De Mikaël BARBERO - Dimanche 16 Décembre 2001 à 15:54

A la fin de ton article tu dis : "error_reporting = E_ALL [code plus propre, sécurité(?)]
Toutes les erreurs de scripts sont signalées, dont celles pouvant survenir lorsqu'une variable est utilisée sans être préalablement déclarée. "

Comment déclares-tu une variable en php ???
Il faut qu'on fasse des settype partout ???
Merci pour ton article, je l'attendais avec impatience !

  Re: Error Reporting ? 
 De J-Pierre Dézélus - Dimanche 16 Décembre 2001 à 16:06

J'ai mal traduit le texte (disponible dans php.ini-recommended).
Il fallait lire en fait "... sans être préalablement initialisée".
Le code suivant sans la 1ère instruction génèrerait donc une erreur.

$a = 0;
while ($a++ < 10)
{
...

PS: je corrige l'article.

  Re: Error Reporting ? 
 De Mikaël BARBERO - Dimanche 16 Décembre 2001 à 16:43

Merci beaucoup.

De toutes façons, il me parait plutot inquiétant que quelqu'un puisse incrémenté une variable sans qu'elle n'est de valeur avant. Celà ne devrait même pas être permis, vous ne trouvez pas ?

  Re: Error Reporting ? 
 De Bertrand DUNOGIER - Dimanche 16 Décembre 2001 à 20:33

Non, PHP se base sur un typage nul (on peut compare un int et un string, assigner à l'arrache, changer le type de variable à la volée... c'est un langage souple au niveau des variables, autant qu'il le reste. Une fois qu'on connait les initialisations par défaut, ca fonctionne, mais il est effectivement très positif que ces "règles" deviennent plus ou moins obligatoire. Un peu de standardisation dans la manière de coder ne fera de mal à personne. Par contre je vais avoir du travail pour revoir mes scripts :)

  Re: Error Reporting ? 
 De Pierre-Alain Joye - Mardi 18 Décembre 2001 à 00:41

Si ca l'est :). Le probleme avec php et les autres langages sans declaration (python) est que du coup on se permet des fantaisies que l'on aurait pas pu faire en c/pascal/java et on l'a tous regrette au moins une fois.
La souplesse de php ne doit pas faire oublier les regles elementaires de programmation.

my last 2FF ;)

  L'avenir de getenv() ? 
 De Laurent Decorps - Vendredi 4 Janvier 2002 à 20:03

la question tient dans son titre ...

  j'upgrade et ca marche pa ! sniff 
 De Aurelien Lemaire - Mardi 8 Janvier 2002 à 15:59

j'ai passé mon system qui marché avec php4.06 a php4.1 et il veut plus m'afficher mes script php:

error: The document contained nodata...blabla
et c tout ?? rien compris
et dans les logs:
->[notice] child pid 5143 exit signal Segmentation fault (11)
->"GET /admin/autologin.php HTTP/1.0" 302 0
->SSLv3 RC4-MD5 "GET /admin/autologin.php HTTP/1.0" 0

navré de vous laché ca comme ca mais moi Grien compris !!!
Qu'est ce qui peut donc merder ???
D'appres l'article si on upgrade ca doit poser aucun problemes !!! et bah moi je l'ai fait --> désolé !

  Et maintenant, que faut il faire? 
 De Julien VALROFF - Mercredi 6 Mars 2002 à 09:01

Moi je me pose une question simple: doit on pour nos scripts actuels privilégier la syntaxe $_* ou non? Par ce que de nombreux hébergeurs gratuits n'en sont pas encore à php4.1.0 (plutôt 4.0.6). Si oui, je ne comprends pas comment on peut faire en sorte que les scripts soient acceptables toutes versions de php confondues...

Ex avec une variable $login transmise par POST!
<?
if(!$login) $login = $HTTP_POST_VARS['login'];
?>

Ok, c'est un début, le script marchera avec php3 mais si la version est >4.1.0, comment on fait pour la syntaxe $_POST?? Faudrait pas quand même détecter la version de php pour faire une série de test du genre if($verPHP>4.1.0) $login = $_POST['login'], si???

Merci pour vos avis d'experts...

  Re: Et maintenant, que faut il faire? 
 De Olivier ISSALY - Dimanche 14 Avril 2002 à 19:33

salut,

tu peux tester avec la constante PHP_VERSION par exemple

  $HTTP_POST_FILES ? 
 De Olivier ISSALY - Dimanche 14 Avril 2002 à 19:29

Salut,
un petit oubli dans l'article il manque le tableau $HTTP_POST_FILES qui devient $_FILES .

merci pour cet article qui aide à faire la transition :)

  Inquietudes 
 De Lionel BALME - Mardi 16 Avril 2002 à 02:53

Une petite remarque a propos du changement de gestion des variables globales.
De tels amenagements dans un langage de programmation ne laisse presager rien de bon: D'une part ca genere un travail tres important pour mettre a jour les millions de scripts de part le monde, et d'autre part, pour combien de temps ? Qu'est-ce qui garantie que les tableaux $_* ne seront pas remplacer par d'autres dans 1 an ou 2, et que le meme travail de maintenance des scripts sera a refaire ?
C'est un vrai pb. PHP est plutot une bonne techno, mais la, j'avoue que je perd un peu confiance. Comment je garantie la perenite de mes scripts dans le futur ? Peut-ete en m'orientant vers une technologie qui offre un peu plus de "visibilite" en ayant un mode d'evolution un peu plus "rigoureux".
Peut-etre qu'a l'avenir, je reflechirais un peu plus avant de choisir PHP pour un projet.
Dommage.