Bonjour à tous,
 
Voilà on a une appli en PHP/HTML qui tourne en intranet avec un serveur apache 1.3.27 et php 4.3.2. Tout marche super bien chez nous et chez de nombreux clients, seulement là on a un cas particulier  
 
PHP n'arrive pas à récupérer la valeur des variables passées en paramètres par un formulaire tout bête.  
 
C'est du genre login, mot de passe. Il appelle bien le fichier, mais comme il n'arrive pas à voir les valeurs, il me redirige vers la page de connexion. Et toutes variables passées en paramètre même en manuel ne s'affichent pas... vous savez le truc tout con je tape dans l'url (chemin)/ident.php?login=toto&mdp=toto et dans ce fichier quand je fais echo $login; j'ai rien du tout
 
L'environnement est W2K avec terminal server et citrix metaframe....:sarcastic: je sais, ça aide pas.
 
Donc si vous avez des infos sur la config ou ne serait-ce qu'une idée sur l'origine du problème, vous êtes le bienvenu.  
 
D'après vous, est-ce que la constante HTTP_USER_AGENT à un rapport dans le sens ou pour des postes "normaux", il s'agit de Mozilla, existe t'il d'autres interpréteurs qui ne seraient pas compatibles avec PHP ?
 
Dernière chose, il s'agit de Internet Explorer 5.0
 
D'avance un grand merci pour votre aide

selon que  

dans php.ini, tu accèderas aux variables par $nom_var ou $HTTP_*_VARS['nom_var'].
le * est à remplacer  
- par GET si le paramètre est passé dans l'url
- par POST si il est issu d'un formulaire
- par COOKIE si il provient d'un cookie.
 
je suppose que c'est le seul serveur correctement configuré et un minimum sécurisé... il a donc "register_globals = off".
 
[hors sujet]
j'ai peut-être la critique facile, mais ça me semble un beau brol ton truc... "encore une boite qui se dit savoir développer en PHP et qui fait n'importe quoi".
j'espère franchement me tromper, mais il faut un minimum de connaissance avant de se lancer dans ce genre de développement
Ne t'enflamme pas trop vite en lisant ça, ça me prend des fois, mais ça m'empêche pas d'aider les autres et d'avoir du respect qd leur travail est bien fait.
j'aime pas le travail baclé.
[/hors sujet]

[hors sujet]
Nos applications sont en Access principalement, et on a mis une appli en php pour avoir un accès plus rapide aux données. Ce n'est pas notre activité principale. Ce qui explique qu'on en peux pas être des experts dans ce langage, cependant je suis arrivé en cours et il est vrai que le code n'est pas toujours très propre... mais bon on ne vend pas cette partie du logiciel, c'est une aide pour les accès trop lent, un petit plus en fait, donc pas de quoi recruter un expert. Donc la critique est certe un peu facile n'ayant rien vu de l'appli, je doutes que tu puisses juger avec si peu d'infos. Cependant je ne m'enflamme pas et comprends ton point de vue.
[/hors sujet]
 
Le truc c'est que visiblement il ne va pas chercher le bon php.ini. En fait on a tout installé chez ce client du coup on installe notre propre php.ini avec le register_globals à "on"...je sais ce que tu vas me dire . Il y a un php.ini qui traine et on ne le trouve pas, malgré une recherche approfondie. Pourtant dans le phpinfo() la var configuration file (php.ini) path est à cwinnt/php.ini et pourtant il n'affiche pas les valeurs qui sont contenues dans ce fichier php.ini.... Je ne sais pas lequel il interprête. En plus on fait à distance donc c'est pas évident

Il arrive pas à accéder au php.ini en fait et il prend des valeurs par défaut genre register_globals à off, pourtant les dossiers ne sont pas protégés et dans phpinfo() il voit bien ou se trouve le fichier php.ini.

[hors sujet]
ok je n'ai rien dis je comprends ta situation.
(c'est rare d'avoir qq qui reste aussi courtois qd on lui fais des remarques   )
visiblement tu y connais un peu plus qu'il n'y parraissait au premier abord.  Il arrive parfois (souvent) que l'on rencontre ce genre de question avec des newbies, donc venant de qq qui développe une appli commerciale, ça m'inquiétait
Je ne dis pas non plus qu'il faille tout connaitre, mais comment développer une appli multi-plateforme sans savoir que selon la config php, le code tournera différemment (register_globals, magic_quotes_gpc, magic_quotes_runtime,...).
je vois mal la boite de développemetn dire au client qu'il faut modifier son php.ini et recoder toute les autres applications pcq elles n'ont pas été conçues pour tel config...
[/hors sujet]
 
Juste pour être sûr que le problème se situe bien là, as tu testé un echo $HTTP_POST_VARS['login'] ?
 
je connais très peu l'install sous Windows
je suppose que tu as copié ton php.ini dans le rep par défaut (commun à toute les install).
 
La seule possibilité qui me vient à l'esprit est que apache/php n'a pas de droit en lecture sur php.ini

ouais ben justement il voit bien le php.ini mais il ne le lit pas. On va tester en mettant le php.ini dans documents and settings/(nom connexion)/windows car en fait sous metaframe, il créé une session à chaque connexion sur le serveur comme différents profils utilisateurs sous windows.
 
Je connais pas ce type de système, c'est la merde plutôt qu'autre chose ! L'idée est sympa mais c'est pas toujours évident.  
 
Si je fais ça : $HTTP_GET_VARS['login']; ça marche bien, et c'est normal car register_globals est bien à 'off' quand on lance phpinfo() par contre il est à 'on' dans le fichier php.ini. Aussi on a essayer en changeant include_path et il ne les interprête pas. Donc on est sûr qu'il ne le lit pas.
 
Il n'a peut-être pas de droits en lecture, mais pkoi   Y'a pas de raisons, puisque ça marche niquel dans des configs de réseaux classiques.  
 
Juste une chose, dans le httpd.conf de apache, on met un lien vers une dll de php pour l'avoir en module -->  
LoadModule php4_module CApache/php/sapi/php4apache.dll Doit-on utiliser une autre dll dans le cadre de métaframe ?
 
Pour le hors sujet, on teste les variables critiques genre magic_quote et on adapte selon... mais l'évolution pour avoir un code propre est prévue mais ce n'est pas une priorité vu que c'est pas le plus important... mais nous petits développeurs on se bat pour faire passer l'évolution que ces messieurs les chefs ne pensent pas encore utiles  

je connais pas du tout metaframe (je travaille sous linux )
Donc, je ne vais sans doute plus t'être d'une grande aide...
je dirais que le metaframe n'est pas la cause du problème mais pour ce que j'en ai compris, je suis certainement largué.
 
le serveur apache/php (tu es sur apache ?) il tourne sur win2k.
il a fallut le lancer en service je suppose, sous quel user/group ? est-ce que ce groupe a le droit de lire le fichier de config ?
Regarde le log généré.  Si tu es sur apache (là au moins je suis sûr), il devrait te dire pourquoi il ne lit pas le php.ini que tu lui donnes.

On a tout réinstallé et....c'est pire maintenant, il a trouvé le php.ini, il lit dedans mais il avait un prob avec l'include path... donc on l'a modifié le php.ini) et depuis il mouline grave sur les fichiers et ne retourne rien... en fait métaframe a posé quelques soucis car il a foutu des verrous sur apache au moment où on voulait le supprimer, on ne pouvait même plus utilser Ajout/Suppression de programmes. Donc il allait bien me chercher le bon fichier mais il a autre chose derrière. Bref, le truc trop chaud à distance.
 
Bref, on va faire une passe sur le code en récupérant les variables plus proprement, en douce   et puis on reprendra tout depuis le début. En tout cas merci pour ton aide.
 
@ +  

au fait, tu avais trouvé qqch dans les logs ?
Normalement, le path de php.ini est hardcodé dans la librairie php4apache.dll (lors de la compilation)
 
oulala je bosserai jamais sur un metaframe moi
 
PS : c'est qd même plus chouette le PHP que l'access hein  

ouais c'est sûr, donc on prend son temps quand on code en php, pour être sûr de rester là-dedans et pas toucher à ce veau d'access.    
 
Non, pas vu les logs, on a abandonné, on reviendra plus tard.