probleme de paiement atos avec ma config php.ini
Le
webvisio
bonjour
pour des raisons de sécurité j'ai mis les variables
suivantes dans le php.ini
register_globals = On
safe_mode = On
depuis que j'ai changé ces variables certains clients ne peuvent plus faire
de paiement securise avec le systeme atos
merci de votre aide
bernard
pour des raisons de sécurité j'ai mis les variables
suivantes dans le php.ini
register_globals = On
safe_mode = On
depuis que j'ai changé ces variables certains clients ne peuvent plus faire
de paiement securise avec le systeme atos
merci de votre aide
bernard
Poser une question
mauvaise idée... pour la améliorer sécurité il faut register_globals = Off
bonne idée
Il leurs suffit de programmer correctement pour que ça fonctionne. Ces
paramètres ne sont pas incompatible avec le system Atos...
register_globals = Off
tu es sur de cette variable car sur des forums il preconisent la valeur a On
Oui je suis sur... dans le doute faire confiance au Bon Dieu
(www.php.net) plutot qu'a ses Saints (les forums en tout genre...)
Cf le lien :
http://fr.php.net/manual/fr/languag...efined.php
Le paragraphe intéressant étant :
Depuis la version PHP 4.2.0, la valeur par défaut de la directive PHP
register_globals est off. Ceci est une évolution majeure de PHP. Avoir
la directive register_globals à off affecte les variables prédéfinies du
contexte globale.
Et concernant les pbs de sécurité lié à cette variable :
http://fr.php.net/manual/fr/security.globals.php et
http://fr.php.net/manual/fr/ini.sec...er-globals
A+
--
Pozzo
imo la seule documentation fiable pour ce genre de questions se trouve à
la source
http://fr3.php.net/manual/fr/security.globals.php
Maintenant, rien ne t'empêches de la mettre à On, mais c'est pas secure
du tout de la mettre à On. L'exemple 15-19 bien que simpliste est
l'illustration parfaite du problème de register_globals
Laurent
Faut arreter de dire que register_globals est secure ou pas. Le problème
de securité viens plutôt des utilisateurs gorets qui codent après. Mais
je prefere amplement voir un script tourné sur une machine à On, mais
qui fonctionne bien et qui est codé proprement, plutôt que des scripts
"sécurisés" en Off qui se font avoir à la premiere injection SQL venu.
Quand à l'exemple 15-19, c'est la preuve d'un... eu comment c'est déjà,
ha oui, Grouik power codage ! Qui si cela avait été correctement codé,
il n'y aurait pas eu de problème. Alors vous me direz, Oui, mais si tout
l'informatique avait été bien codé, il n'y aurait pas de failles. Il y a
les erreurs de codages qui peuvent arriver et celle qui ne peuvent pas
quand on code proprement (avec un rapport d'erreur à E_ALL, qui permet
de se rendre trés vite compte que quelque chose plante)
Mais bon, ce n'est que la X ieme foix que l'on le dit... (Remplacez X
par une valeur comprit entre l'infinit et un peut plus.)
--
Guillaume.