Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne
se fait plus de la même façon, je m'explique auparavant j'avais une varaible
HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la
valeur par la variable $type, maintenant apparement il faut faire appel à la
variable $_POST["type"], ce n'est pas pratique, comment faire? quelqu'un a
t'il déja recontrer ce pb?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Guillaume Bouchard
Ludo wrote:
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne se fait plus de la même façon, je m'explique auparavant j'avais une varaible HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la valeur par la variable $type, maintenant apparement il faut faire appel à la variable $_POST["type"], ce n'est pas pratique, comment faire? quelqu'un a t'il déja recontrer ce pb?
Bonjour. Moi au contraire je trouve cela hyper pratique, l'on sais d'ou vienent nos variables.
Lectures
http://phpinfo.net/articles/article_globals.html
-- Guillaume.
Ludo wrote:
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne
se fait plus de la même façon, je m'explique auparavant j'avais une varaible
HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la
valeur par la variable $type, maintenant apparement il faut faire appel à la
variable $_POST["type"], ce n'est pas pratique, comment faire? quelqu'un a
t'il déja recontrer ce pb?
Bonjour.
Moi au contraire je trouve cela hyper pratique, l'on sais d'ou vienent
nos variables.
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne se fait plus de la même façon, je m'explique auparavant j'avais une varaible HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la valeur par la variable $type, maintenant apparement il faut faire appel à la variable $_POST["type"], ce n'est pas pratique, comment faire? quelqu'un a t'il déja recontrer ce pb?
Bonjour. Moi au contraire je trouve cela hyper pratique, l'on sais d'ou vienent nos variables.
Lectures
http://phpinfo.net/articles/article_globals.html
-- Guillaume.
Leonard Wauters
On 20 Aug 2003 14:10:15 GMT, Ludo wrote:
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne se fait plus de la même façon, je m'explique auparavant j'avais une varaible HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la valeur par la variable $type, maintenant apparement il faut faire appel à la variable $_POST["type"], ce n'est pas pratique, comment faire? quelqu'un a t'il déja recontrer ce pb?
register_globals dans php.ini cf la doc.
merci d'avance!
On 20 Aug 2003 14:10:15 GMT, Ludo <loulou9000@freesurf.fr> wrote:
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne
se fait plus de la même façon, je m'explique auparavant j'avais une varaible
HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la
valeur par la variable $type, maintenant apparement il faut faire appel à la
variable $_POST["type"], ce n'est pas pratique, comment faire? quelqu'un a
t'il déja recontrer ce pb?
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne se fait plus de la même façon, je m'explique auparavant j'avais une varaible HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la valeur par la variable $type, maintenant apparement il faut faire appel à la variable $_POST["type"], ce n'est pas pratique, comment faire? quelqu'un a t'il déja recontrer ce pb?
register_globals dans php.ini cf la doc.
merci d'avance!
P'tit Marcel
Ludo écrivit:
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne se fait plus de la même façon, je m'explique auparavant j'avais une varaible HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la valeur par la variable $type, maintenant apparement il faut faire appel à la variable $_POST["type"], ce n'est pas pratique, comment faire?
Lis déjà l'article "un trou de sécurité" signalé par Guillaume pour comprendre l'intérêt de la nouvelle méthode.
Si cela ne te convient toujours pas, tu peux toujours ajouter en début de script : extract($_POST);
Tu peux aussi modifier la valeur du paramètre register_globals soit dans php.ini soit dans un .htaccess (si sous Apache). La modif impactera tous les scripts php du serveur respectivement tous ceux du répertoire.
eça -- P'tit Marcel statistiques sur les forums modérés : http://www.centrale-lyon.org/ng/
Ludo écrivit:
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables
post ne se fait plus de la même façon, je m'explique auparavant
j'avais une varaible HTML de type HIDDEN qui s'appelait type, après un
submit, j'accédais à la valeur par la variable $type, maintenant
apparement il faut faire appel à la variable $_POST["type"], ce n'est
pas pratique, comment faire?
Lis déjà l'article "un trou de sécurité" signalé par Guillaume pour
comprendre l'intérêt de la nouvelle méthode.
Si cela ne te convient toujours pas, tu peux toujours ajouter en début de
script :
extract($_POST);
Tu peux aussi modifier la valeur du paramètre register_globals soit dans
php.ini soit dans un .htaccess (si sous Apache). La modif impactera tous
les scripts php du serveur respectivement tous ceux du répertoire.
eça
--
P'tit Marcel
statistiques sur les forums modérés : http://www.centrale-lyon.org/ng/
Bonjour, j'ai installé php Version 4.2.3 et le nommage des variables post ne se fait plus de la même façon, je m'explique auparavant j'avais une varaible HTML de type HIDDEN qui s'appelait type, après un submit, j'accédais à la valeur par la variable $type, maintenant apparement il faut faire appel à la variable $_POST["type"], ce n'est pas pratique, comment faire?
Lis déjà l'article "un trou de sécurité" signalé par Guillaume pour comprendre l'intérêt de la nouvelle méthode.
Si cela ne te convient toujours pas, tu peux toujours ajouter en début de script : extract($_POST);
Tu peux aussi modifier la valeur du paramètre register_globals soit dans php.ini soit dans un .htaccess (si sous Apache). La modif impactera tous les scripts php du serveur respectivement tous ceux du répertoire.
eça -- P'tit Marcel statistiques sur les forums modérés : http://www.centrale-lyon.org/ng/
John GALLET
Bonjour,
Lis déjà l'article "un trou de sécurité"
Décidement c'est la journée : encore une fois HALTE AUX CONNERIES. Coder en register_globals à On n'a jamais amené d'autres trous de sécurité que ceux que les développeurs du dimanche qui ne savent pas coder y ont introduit.
PHP a toujours été un langage sécurisé, en register_globals On ou Off. Ceux qui l'écrivent, c'est une autre histoire.
Et je vous raconte pas la fête du slip version foire du trône avec barbes à papa (special kasdedi à AF) des scripts écrits avec un développeur qui pense qu'il aura toujours register_globals à Off sur sa plateforme le jour où le machin se retrouve avec du On... Ca oui, c'est un trou de sécurité, de pouvoir revenir en arrière.
comprendre l'intérêt de la nouvelle méthode.
Aucun si ce n'est nous emmerder à ajouter une ligne de code dans la fonction standard de filtrage des variables d'entrée :-)
a++ JG
Bonjour,
Lis déjà l'article "un trou de sécurité"
Décidement c'est la journée : encore une fois HALTE AUX CONNERIES. Coder en
register_globals à On n'a jamais amené d'autres trous de sécurité que ceux
que les développeurs du dimanche qui ne savent pas coder y ont introduit.
PHP a toujours été un langage sécurisé, en register_globals On ou Off. Ceux
qui l'écrivent, c'est une autre histoire.
Et je vous raconte pas la fête du slip version foire du trône avec barbes à
papa (special kasdedi à AF) des scripts écrits avec un développeur qui pense
qu'il aura toujours register_globals à Off sur sa plateforme le jour où le
machin se retrouve avec du On... Ca oui, c'est un trou de sécurité, de
pouvoir revenir en arrière.
comprendre l'intérêt de la nouvelle méthode.
Aucun si ce n'est nous emmerder à ajouter une ligne de code dans la fonction
standard de filtrage des variables d'entrée :-)
Décidement c'est la journée : encore une fois HALTE AUX CONNERIES. Coder en register_globals à On n'a jamais amené d'autres trous de sécurité que ceux que les développeurs du dimanche qui ne savent pas coder y ont introduit.
PHP a toujours été un langage sécurisé, en register_globals On ou Off. Ceux qui l'écrivent, c'est une autre histoire.
Et je vous raconte pas la fête du slip version foire du trône avec barbes à papa (special kasdedi à AF) des scripts écrits avec un développeur qui pense qu'il aura toujours register_globals à Off sur sa plateforme le jour où le machin se retrouve avec du On... Ca oui, c'est un trou de sécurité, de pouvoir revenir en arrière.
comprendre l'intérêt de la nouvelle méthode.
Aucun si ce n'est nous emmerder à ajouter une ligne de code dans la fonction standard de filtrage des variables d'entrée :-)
a++ JG
Guillaume Bouchard
John GALLET wrote:
Décidement c'est la journée : encore une fois HALTE AUX CONNERIES. Coder en register_globals à On n'a jamais amené d'autres trous de sécurité que ceux que les développeurs du dimanche qui ne savent pas coder y ont introduit.
Entieremeznt d'accord, mais register_global a off apporte une securité de plus pour les developpeur du dimanche et un garantie pour les developpeur du lundi qui savent coder, mais qui ont fait une erreur.
Je pense qu'il y a trés peux de developpeur parfaits qui ne font pas d'erreur, sinon il serait tous a bosser chez Microsft et l'on entendrait pas parler des attaques de worms en ce moment.
Et je vous raconte pas la fête du slip version foire du trône avec barbes à papa (special kasdedi à AF) des scripts écrits avec un développeur qui pense qu'il aura toujours register_globals à Off sur sa plateforme le jour où le machin se retrouve avec du On... Ca oui, c'est un trou de sécurité, de pouvoir revenir en arrière.
C'est malheureusement vrai...
comprendre l'intérêt de la nouvelle méthode.
Aucun si ce n'est nous emmerder à ajouter une ligne de code dans la fonction standard de filtrage des variables d'entrée :-)
L'interet de la nouvelle methode, c'est que a la relecture l'on sais plus facilement d'ou vient une variable, avant mes codes sources ressemblaient à ca:
# $toto provient de GET lala $toto;
Maitenant à ca,
echo $_GET['toto'];
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de personne se donnais la peine d'indiquer ce genre de commentaires.
-- Guillaume.
John GALLET wrote:
Décidement c'est la journée : encore une fois HALTE AUX CONNERIES. Coder en
register_globals à On n'a jamais amené d'autres trous de sécurité que ceux
que les développeurs du dimanche qui ne savent pas coder y ont introduit.
Entieremeznt d'accord, mais register_global a off apporte une securité
de plus pour les developpeur du dimanche et un garantie pour les
developpeur du lundi qui savent coder, mais qui ont fait une erreur.
Je pense qu'il y a trés peux de developpeur parfaits qui ne font pas
d'erreur, sinon il serait tous a bosser chez Microsft et l'on entendrait
pas parler des attaques de worms en ce moment.
Et je vous raconte pas la fête du slip version foire du trône avec barbes à
papa (special kasdedi à AF) des scripts écrits avec un développeur qui pense
qu'il aura toujours register_globals à Off sur sa plateforme le jour où le
machin se retrouve avec du On... Ca oui, c'est un trou de sécurité, de
pouvoir revenir en arrière.
C'est malheureusement vrai...
comprendre l'intérêt de la nouvelle méthode.
Aucun si ce n'est nous emmerder à ajouter une ligne de code dans la fonction
standard de filtrage des variables d'entrée :-)
L'interet de la nouvelle methode, c'est que a la relecture l'on sais
plus facilement d'ou vient une variable, avant mes codes sources
ressemblaient à ca:
# $toto provient de GET
lala $toto;
Maitenant à ca,
echo $_GET['toto'];
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de
personne se donnais la peine d'indiquer ce genre de commentaires.
Décidement c'est la journée : encore une fois HALTE AUX CONNERIES. Coder en register_globals à On n'a jamais amené d'autres trous de sécurité que ceux que les développeurs du dimanche qui ne savent pas coder y ont introduit.
Entieremeznt d'accord, mais register_global a off apporte une securité de plus pour les developpeur du dimanche et un garantie pour les developpeur du lundi qui savent coder, mais qui ont fait une erreur.
Je pense qu'il y a trés peux de developpeur parfaits qui ne font pas d'erreur, sinon il serait tous a bosser chez Microsft et l'on entendrait pas parler des attaques de worms en ce moment.
Et je vous raconte pas la fête du slip version foire du trône avec barbes à papa (special kasdedi à AF) des scripts écrits avec un développeur qui pense qu'il aura toujours register_globals à Off sur sa plateforme le jour où le machin se retrouve avec du On... Ca oui, c'est un trou de sécurité, de pouvoir revenir en arrière.
C'est malheureusement vrai...
comprendre l'intérêt de la nouvelle méthode.
Aucun si ce n'est nous emmerder à ajouter une ligne de code dans la fonction standard de filtrage des variables d'entrée :-)
L'interet de la nouvelle methode, c'est que a la relecture l'on sais plus facilement d'ou vient une variable, avant mes codes sources ressemblaient à ca:
# $toto provient de GET lala $toto;
Maitenant à ca,
echo $_GET['toto'];
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de personne se donnais la peine d'indiquer ce genre de commentaires.
-- Guillaume.
John GALLET
Re,
Entieremeznt d'accord, mais register_global a off apporte une securité de plus pour les developpeur du dimanche et un garantie pour les developpeur du lundi qui savent coder, mais qui ont fait une erreur.
De la part d'un grand fana du error_reporting E_ALL comme toi, j'ai peine à apprécier pleinement le sens de la remarque ;-))
L'interet de la nouvelle methode, c'est que a la relecture l'on sais plus facilement d'ou vient une variable, avant mes codes sources ressemblaient à ca: # $toto provient de GET lala $toto; Maitenant à ca, echo $_GET['toto'];
Si c'est tout de qu'il te faut, il suffit d'avoir une convention de nommage : tout ce qui commence par $l_ c'est LOCALE, $i_ c'est du IN, $o_ c'est du OUT $x_ c'est du IN/OUT (fonctions) et $z_ du monde extérieur par exemple. Enfin comme de toutes façons depuis mathusalem toute variable externe me revient de la fonction maison fx_filtrer($nom_var, $type='ALL') qui s'utilise dans le genre : $l_email=fx_filtrer('email', 'EMAIL'); $l_qte=fx_filtrer('qte_commandee', 'INT'); $l_ref=fx_filtrer('ref_produit'); pour les variables email, qte_commandee et ref_produit qui arrivent de l'internaute, je ne me suis jamais posé la question de savoir d'où viennent mes variables : elles sont toutes locales au script. Seule la fonction fx_filtrer() est autorisée à tripoter les données venant de l'extérieur.
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de personne se donnais la peine d'indiquer ce genre de commentaires. Pour autant que ce soit utile...
Même sans faire une fonction de filtrage, il suffit d'une fonction bête qui fait en gros : function get_arg($nom) { if(isset($_REQUEST[$nom])) return $_REQUEST[$nom]; return ''; } bref typiquement ce qu'on écrirait en macro en C pour éviter de s'emm... avec des tests partout et ensuite on a seulement des variables locales. Il suffit de les initialiser proprement si elles ne sont pas affectées via cette fonction, c'est quand même pas difficile, à tout casser on a 5 ou 10 variables locales à un script principal en plus de celles qui viennent de l'extérieur.
a++ JG
Re,
Entieremeznt d'accord, mais register_global a off apporte une securité
de plus pour les developpeur du dimanche et un garantie pour les
developpeur du lundi qui savent coder, mais qui ont fait une erreur.
De la part d'un grand fana du error_reporting E_ALL comme toi, j'ai peine à
apprécier pleinement le sens de la remarque ;-))
L'interet de la nouvelle methode, c'est que a la relecture l'on sais
plus facilement d'ou vient une variable, avant mes codes sources
ressemblaient à ca:
# $toto provient de GET
lala $toto;
Maitenant à ca,
echo $_GET['toto'];
Si c'est tout de qu'il te faut, il suffit d'avoir une convention de nommage
: tout ce qui commence par $l_ c'est LOCALE, $i_ c'est du IN, $o_ c'est du
OUT $x_ c'est du IN/OUT (fonctions) et $z_ du monde extérieur par exemple.
Enfin comme de toutes façons depuis mathusalem toute variable externe me
revient de la fonction maison fx_filtrer($nom_var, $type='ALL') qui
s'utilise dans le genre :
$l_email=fx_filtrer('email', 'EMAIL');
$l_qte=fx_filtrer('qte_commandee', 'INT');
$l_ref=fx_filtrer('ref_produit');
pour les variables email, qte_commandee et ref_produit qui arrivent de
l'internaute, je ne me suis jamais posé la question de savoir d'où viennent
mes variables : elles sont toutes locales au script. Seule la fonction
fx_filtrer() est autorisée à tripoter les données venant de l'extérieur.
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de
personne se donnais la peine d'indiquer ce genre de commentaires.
Pour autant que ce soit utile...
Même sans faire une fonction de filtrage, il suffit d'une fonction bête qui
fait en gros :
function get_arg($nom)
{
if(isset($_REQUEST[$nom])) return $_REQUEST[$nom];
return '';
}
bref typiquement ce qu'on écrirait en macro en C pour éviter de s'emm...
avec des tests partout et ensuite on a seulement des variables locales. Il
suffit de les initialiser proprement si elles ne sont pas affectées via
cette fonction, c'est quand même pas difficile, à tout casser on a 5 ou 10
variables locales à un script principal en plus de celles qui viennent de
l'extérieur.
Entieremeznt d'accord, mais register_global a off apporte une securité de plus pour les developpeur du dimanche et un garantie pour les developpeur du lundi qui savent coder, mais qui ont fait une erreur.
De la part d'un grand fana du error_reporting E_ALL comme toi, j'ai peine à apprécier pleinement le sens de la remarque ;-))
L'interet de la nouvelle methode, c'est que a la relecture l'on sais plus facilement d'ou vient une variable, avant mes codes sources ressemblaient à ca: # $toto provient de GET lala $toto; Maitenant à ca, echo $_GET['toto'];
Si c'est tout de qu'il te faut, il suffit d'avoir une convention de nommage : tout ce qui commence par $l_ c'est LOCALE, $i_ c'est du IN, $o_ c'est du OUT $x_ c'est du IN/OUT (fonctions) et $z_ du monde extérieur par exemple. Enfin comme de toutes façons depuis mathusalem toute variable externe me revient de la fonction maison fx_filtrer($nom_var, $type='ALL') qui s'utilise dans le genre : $l_email=fx_filtrer('email', 'EMAIL'); $l_qte=fx_filtrer('qte_commandee', 'INT'); $l_ref=fx_filtrer('ref_produit'); pour les variables email, qte_commandee et ref_produit qui arrivent de l'internaute, je ne me suis jamais posé la question de savoir d'où viennent mes variables : elles sont toutes locales au script. Seule la fonction fx_filtrer() est autorisée à tripoter les données venant de l'extérieur.
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de personne se donnais la peine d'indiquer ce genre de commentaires. Pour autant que ce soit utile...
Même sans faire une fonction de filtrage, il suffit d'une fonction bête qui fait en gros : function get_arg($nom) { if(isset($_REQUEST[$nom])) return $_REQUEST[$nom]; return ''; } bref typiquement ce qu'on écrirait en macro en C pour éviter de s'emm... avec des tests partout et ensuite on a seulement des variables locales. Il suffit de les initialiser proprement si elles ne sont pas affectées via cette fonction, c'est quand même pas difficile, à tout casser on a 5 ou 10 variables locales à un script principal en plus de celles qui viennent de l'extérieur.
a++ JG
Guillaume Bouchard
John GALLET wrote:
Entieremeznt d'accord, mais register_global a off apporte une securité de plus pour les developpeur du dimanche et un garantie pour les developpeur du lundi qui savent coder, mais qui ont fait une erreur.
De la part d'un grand fana du error_reporting E_ALL comme toi, j'ai peine à apprécier pleinement le sens de la remarque ;-))
Mais tout le monde n'a pas ma conscience de mettre tout en E_ALL :)
Si c'est tout de qu'il te faut, il suffit d'avoir une convention de nommage : tout ce qui commence par $l_ c'est LOCALE, $i_ c'est du IN, $o_ c'est du OUT $x_ c'est du IN/OUT (fonctions) et $z_ du monde extérieur par exemple.
Oué, mais tu sais que dans un souci d'optimisation enorme, je ne diuplique jamais mes variables tels que $_POST dans autre chose :) donc je devrais nommer mes formulaire name="z_xxxxxx" ca fait lourd :)
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de personne se donnais la peine d'indiquer ce genre de commentaires.
Pour autant que ce soit utile...
Dans le cas de script bien fait avec ta fonction fx_filtration, ce n'est pas utile, mais souvent j'ai pu voir des trucs du genre
if($truc = 'toto')
Et là tu te demandes d'ou vient $truc, tu cherches dans les includes, les autres bouts de script puis tu imagine que cela vient de l'exterieur...
-- Guillaume.
John GALLET wrote:
Entieremeznt d'accord, mais register_global a off apporte une securité
de plus pour les developpeur du dimanche et un garantie pour les
developpeur du lundi qui savent coder, mais qui ont fait une erreur.
De la part d'un grand fana du error_reporting E_ALL comme toi, j'ai peine à
apprécier pleinement le sens de la remarque ;-))
Mais tout le monde n'a pas ma conscience de mettre tout en E_ALL :)
Si c'est tout de qu'il te faut, il suffit d'avoir une convention de nommage
: tout ce qui commence par $l_ c'est LOCALE, $i_ c'est du IN, $o_ c'est du
OUT $x_ c'est du IN/OUT (fonctions) et $z_ du monde extérieur par exemple.
Oué, mais tu sais que dans un souci d'optimisation enorme, je ne
diuplique jamais mes variables tels que $_POST dans autre chose :) donc
je devrais nommer mes formulaire name="z_xxxxxx" ca fait lourd :)
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de
personne se donnais la peine d'indiquer ce genre de commentaires.
Pour autant que ce soit utile...
Dans le cas de script bien fait avec ta fonction fx_filtration, ce n'est
pas utile, mais souvent j'ai pu voir des trucs du genre
if($truc = 'toto')
Et là tu te demandes d'ou vient $truc, tu cherches dans les includes,
les autres bouts de script puis tu imagine que cela vient de l'exterieur...
Entieremeznt d'accord, mais register_global a off apporte une securité de plus pour les developpeur du dimanche et un garantie pour les developpeur du lundi qui savent coder, mais qui ont fait une erreur.
De la part d'un grand fana du error_reporting E_ALL comme toi, j'ai peine à apprécier pleinement le sens de la remarque ;-))
Mais tout le monde n'a pas ma conscience de mettre tout en E_ALL :)
Si c'est tout de qu'il te faut, il suffit d'avoir une convention de nommage : tout ce qui commence par $l_ c'est LOCALE, $i_ c'est du IN, $o_ c'est du OUT $x_ c'est du IN/OUT (fonctions) et $z_ du monde extérieur par exemple.
Oué, mais tu sais que dans un souci d'optimisation enorme, je ne diuplique jamais mes variables tels que $_POST dans autre chose :) donc je devrais nommer mes formulaire name="z_xxxxxx" ca fait lourd :)
Et dans les scripts pré_register_global_off que j'ai pu voir, peux de personne se donnais la peine d'indiquer ce genre de commentaires.
Pour autant que ce soit utile...
Dans le cas de script bien fait avec ta fonction fx_filtration, ce n'est pas utile, mais souvent j'ai pu voir des trucs du genre
if($truc = 'toto')
Et là tu te demandes d'ou vient $truc, tu cherches dans les includes, les autres bouts de script puis tu imagine que cela vient de l'exterieur...
-- Guillaume.
P'tit Marcel
John GALLET écrivit:
Le débat faut-il programmer ou non en register_globals on ou off, pour moi c'est bruit blanc. L'adaptation de mes scripts quand c'est passé en Off par défaut m'a prit une ligne de plus dans une seule fonction. Ce qui me fait grogner, c'est le titre "un trou de sécurité" qui sous entend que PHP avait un trou de sécurité qui a été corrigé. Et le trou en question se situe clairement dans l'interface chaise-clavier.
Là j'opine. Au lancement de la 4.2 on a lu des explications doctes comme quoi un grave défaut de php avait été corrigé, que grâce à ça php devenait un outil professionnel, gnagnagna. C'était vraiment prendre les gens pour des cons. Le vrai bon changement aurait été d'interdire l'emploi de variables non définies en faisant passer son niveau de gravité de E_NOTICE à E_ERROR.
Effectivement l'article de phpinfo reprend la thèse 'officielle' sans réflexion. Il faudrait que je retrouve les articles critiques écrits par Rasmus L. à l'époque...
-- P'tit Marcel
John GALLET écrivit:
Le débat faut-il programmer ou non en register_globals on ou off, pour
moi c'est bruit blanc. L'adaptation de mes scripts quand c'est passé
en Off par défaut m'a prit une ligne de plus dans une seule fonction.
Ce qui me fait grogner, c'est le titre "un trou de sécurité" qui sous
entend que PHP avait un trou de sécurité qui a été corrigé. Et le trou
en question se situe clairement dans l'interface chaise-clavier.
Là j'opine. Au lancement de la 4.2 on a lu des explications doctes comme
quoi un grave défaut de php avait été corrigé, que grâce à ça php devenait
un outil professionnel, gnagnagna. C'était vraiment prendre les gens pour
des cons. Le vrai bon changement aurait été d'interdire l'emploi de
variables non définies en faisant passer son niveau de gravité de E_NOTICE
à E_ERROR.
Effectivement l'article de phpinfo reprend la thèse 'officielle' sans
réflexion. Il faudrait que je retrouve les articles critiques écrits par
Rasmus L. à l'époque...
Le débat faut-il programmer ou non en register_globals on ou off, pour moi c'est bruit blanc. L'adaptation de mes scripts quand c'est passé en Off par défaut m'a prit une ligne de plus dans une seule fonction. Ce qui me fait grogner, c'est le titre "un trou de sécurité" qui sous entend que PHP avait un trou de sécurité qui a été corrigé. Et le trou en question se situe clairement dans l'interface chaise-clavier.
Là j'opine. Au lancement de la 4.2 on a lu des explications doctes comme quoi un grave défaut de php avait été corrigé, que grâce à ça php devenait un outil professionnel, gnagnagna. C'était vraiment prendre les gens pour des cons. Le vrai bon changement aurait été d'interdire l'emploi de variables non définies en faisant passer son niveau de gravité de E_NOTICE à E_ERROR.
Effectivement l'article de phpinfo reprend la thèse 'officielle' sans réflexion. Il faudrait que je retrouve les articles critiques écrits par Rasmus L. à l'époque...
-- P'tit Marcel
Hugues Peeters
Il faudrait que je retrouve les articles critiques écrits par Rasmus L. à l'époque...
http://www.sitepoint.com/article/767
INTERVIEW - PHP'S CREATOR, RASMUS LERDORF By Kevin Yank -- May 22nd 2002
SP: What are your views on Magic Quotes and Register Globals?
RL: Register Globals is one of the features that brought people to PHP. The simplicity of creating Web applications when form and other variables were automatically available could not be beaten. I was personally not in favour of turning Register Globals off by default. It adds very little to the overall security of an application. If people do not check data coming from the user then with or without Register Globals enabled that application is going to be insecure. The only time having Register Globals off helps is when you forget to initialize a variable before you use it and someone who knows your code exploits that. By changing the error reporting level you can have PHP find these cases for you automatically. So in the end, all I think turning Register Globals off has done is make writing PHP apps more complicated.
And it has of course also generated 10-20 questions/bug reports per day from users who are confused about this change.
Il faudrait que je retrouve les articles critiques écrits par
Rasmus L. à l'époque...
http://www.sitepoint.com/article/767
INTERVIEW - PHP'S CREATOR, RASMUS LERDORF
By Kevin Yank -- May 22nd 2002
SP: What are your views on Magic Quotes and Register Globals?
RL: Register Globals is one of the features that brought people to PHP.
The simplicity of creating Web applications when form and other
variables were automatically available could not be beaten.
I was personally not in favour of turning Register Globals off by
default. It adds very little to the overall security of an application.
If people do not check data coming from the user then with or without
Register Globals enabled that application is going to be insecure.
The only time having Register Globals off helps is when you forget to
initialize a variable before you use it and someone who knows your code
exploits that. By changing the error reporting level you can have PHP
find these cases for you automatically. So in the end, all I think
turning Register Globals off has done is make writing PHP apps more
complicated.
And it has of course also generated 10-20 questions/bug reports per day
from users who are confused about this change.
Il faudrait que je retrouve les articles critiques écrits par Rasmus L. à l'époque...
http://www.sitepoint.com/article/767
INTERVIEW - PHP'S CREATOR, RASMUS LERDORF By Kevin Yank -- May 22nd 2002
SP: What are your views on Magic Quotes and Register Globals?
RL: Register Globals is one of the features that brought people to PHP. The simplicity of creating Web applications when form and other variables were automatically available could not be beaten. I was personally not in favour of turning Register Globals off by default. It adds very little to the overall security of an application. If people do not check data coming from the user then with or without Register Globals enabled that application is going to be insecure. The only time having Register Globals off helps is when you forget to initialize a variable before you use it and someone who knows your code exploits that. By changing the error reporting level you can have PHP find these cases for you automatically. So in the end, all I think turning Register Globals off has done is make writing PHP apps more complicated.
And it has of course also generated 10-20 questions/bug reports per day from users who are confused about this change.
