Session et formulaire, probleme !!!

Bon déja c que tu as un soucis..:)
perso pour ton register_globals = On, tu peut tout a fait faire un replace dans tout tes fichiers ca c vraiemnt pour certain truc et le reste a la main.
A terme, ca ne sera plus utilisé donc c a toi de voir. Heureusement qu'on peux mettre l'option a on dans le httpd.conf, dans une section directory, ainsi que dans un .htaccess quoi que du coup je doute pour cette option...

Bon pour ton histoire de session ca a rien a voir. Tu peux demarrer une session et recup des trucs d'un form sans probleme.
1- commence par ecrire ton html en minuscule car ce sont les normes.
2-passes au xhtml car il suffit de quelque petite modif de rien
3-la fonction print sux, c'est echo qu'il faut utiliser,
et que personne me sorte des histoire de limitation pasque si un clampin arrive au max d'un echo c que le script est mal pondu.
4-Mieux vaux utiliser la methode post si tu utilise un formulaire.
5-meme si tu est en register_globals = on, utilise les super globale $_POST et $_GET.
Ca ferme un trou de secu en plus et aussi ca ouvre des possibilités, $_POST['toto'] != $_GET['toto'];

et le fait que ca soit vide, dans ton fichier de session t'aurai pas une variable $nom qui serait pas renseignée?
tu vois si tu as un $nom qui vien du post et qui est pas vide et que tu demarre ta session avec dedans une autre du meme nom mais vide....
Ca pose des soucis $_POST['nom'] != $_SESSION['nom'].

Et pour ta gouverne, je me suis scanné a la main les plus de 20 000 ligne de mon appli perso pour changer les variable en focntion du register_globals. :)))
j'espere que ca t'a aidé.
seb

Bonjour,

[register_global]

A terme, ca ne sera plus utilisé
Says who ?

ainsi que dans un .htaccess quoi que du coup je doute pour cette option...

Il ne faut pas douter il faut lire le manuel :
http://fr2.php.net/ini_set
register_globals "0" PHP_INI_PERDIR|PHP_INI_SYSTEM

Donc oui on peut le faire en .htacess, normal d'ailleurs c'est la même
chose qu'une directive Directory (pour PHP en tous cas, je ne arle pas
des restrictions d'apache qui onterdit certaines directives dans les
.htaccess, mais php_value n'en fait pas partie).

1- commence par ecrire ton html en minuscule car ce sont les normes.
[HS] Norme ? Où ça ? Ah oui, standard de marché. Du temps où j'ai appris

le HTML la "norme" était au contraire de l'écrire en majuscules. Si
j'attends suffisement longtemps, ça devrait bien rechanger dans l'autre
sens...

2-passes au xhtml car il suffit de quelque petite modif de rien
[HS] Et comme ça à part les riches qui peuvent se payer un nouveau PC et

la dernière version d'IE plus personne n'a accès aux données. Pile poil.

3-la fonction print sux, c'est echo qu'il faut utiliser,

Ah... "sux". Ca c'est un argument technique de poids. On s'en tape
d'utiliser echo "string" ou echo ("string") ou print("string") c'est
rigoureusement la même chose. Donc dire qu'il est possible d'écrire echo
"machin" au lieu de print("machin") ce qui fait gagner TROIS caractères
(LE PIED!!!) admettons, mais "sux", ça reste très subjectif. Au fait, ça
s'écrit "sucks" pour les non Shakespearophones (même si je doûte qu'il
aurait employé ce terme anachronique).

4-Mieux vaux utiliser la methode post si tu utilise un formulaire.

[HS] Pourquoi ? C'est une norme ça aussi ? A part dans le cas de la
soumission d'un mot de passe pour éviter qu'il soit visible au dessus de
l'épaule de l'internaute par quelqu'un regardant son écran, ceci est une
affirmation gratuite.

5-meme si tu est en register_globals = on, utilise les super globale $_POST et $_GET.
Ca ferme un trou de secu en plus et aussi ca ouvre des possibilités, $_POST['toto'] != $_GET['toto'];

Non pour le trou de sécurité (car il n'a jamais été ouvert donc on ne
peut pas le fermer) car ce n'est pas un problème de sécurité mais
d'interface chaise-clavier et non pour faire la différenciation entre
_GET et _POST, c'est totalement inutile (comprendre : il est aussi
facile d'envoyer n'importe quoi à ton script en GET qu'en POST et c'est
là qu'est la faille de sécurité) et ça donne une fausse impression de
sécurité. Cf les archives on en a déjà suffisement débattu.

Et pour ta gouverne, je me suis scanné a la main les plus de 20 000 ligne de mon
appli perso pour changer les variable en focntion du register_globals. :)))

Moi j'ai changé une ligne et supprimé 3 lignes de code dans ma fonction
de filtrage. Mais bon, chacun son truc hein...

a++
JG

Le Tue, 04 May 2004 10:08:47 +0000, John Gallet a écrit :

Says who ?

C'est marqué dans la doc que tu cite plus bas

ainsi que dans un .htaccess quoi que du coup je doute pour cette option...
Il ne faut pas douter il faut lire le manuel :

Ct un detail de conversation je trouve le ton que tu utilise plus que désagréable

[HS] Norme ? Où ça ? Ah oui, standard de marché. Du temps où j'ai appris
norme w3c, vas donc lire la doc puisque tu me le conseille si joyeusement

[HS] Et comme ça à part les riches qui peuvent se payer un nouveau PC et

Mozilla c'est gratuit, j'en conclu que tu es sous windows...
Opera c'est gratuit
Firefox c'est gratuit
et ca existe sous windows
Linux c'est gratuit
juste fo lire la doc...
et tout les plugins existent pour ces navigateurs
sache aussi que la norme xhtml permet de faire des programme accessible aux handicapé mais toi je suppose que tu en
a rien a foutre qu'il y ai des aveugles et handicapés moteur qui se
servent du web...

d'utiliser echo "string" ou echo ("string") ou print("string") c'est
rigoureusement la même chose.

http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40
tu verras que cela n'ets pas la meme chose, mais encore une fois faut lire la doc

et pour le cours d'anglais merci, mais je parle couremment, sux c'est une expression utilisée sur IRC.

Non pour le trou de sécurité (car il n'a jamais été ouvert donc on ne

parce pour toi que kk1 puisse balancer une variable en get alors que c un post que ton programme recupere c'est pas une erreur??? avec la barre webdevelopper de mozilla on peut convertir les var post en get donc commencer a faire ce qu'on veux....mais bon..

Moi j'ai changé une ligne et supprimé 3 lignes de code dans ma fonction

C'est ton probleme si tu fais du bricolage.
Quand a ton post il ne fais que critiquer l'aide que j'ai apporté sur des point de detail
en en plus tu dis des conneries.
Surtout en ce qui concerne les normes.
Propose au lieu de critiquer.
Seb

C'est marqué dans la doc que tu cite plus bas
URL svp...

[HS]

Ct un detail de conversation je trouve le ton que tu utilise plus que désagréable
Toujours quand je lis des âneries (et que j'ai le temps de les

signaler).

[HS] Norme ? Où ça ? Ah oui, standard de marché. Du temps où j'ai appris
norme w3c, vas donc lire la doc puisque tu me le conseille si joyeusement

C'est bien ce que je disais : standard de marché, pas norme. Mais comme
tu dis "ct" un détail de conversation.

Mozilla c'est gratuit, j'en conclu que tu es sous windows...
:-) Regarde bien les headers de cet article :

X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14-15mdk i686)

Opera c'est gratuit
Firefox c'est gratuit
Oui mais ça tourne qu'en glibc 2.xx et je n'ai pas ça sous la main. Je

ne vais pas passer des heures à réinstaller mon système parce que des
connards ne savent pas ce que veut dire "rétro-compatible".

Linux c'est gratuit
juste fo lire la doc...
Quelle doc ?

et tout les plugins existent pour ces navigateurs
Quand le navigateur en question ne s'installe même pas sur ta version

d'OS tu peux toujours essayer de plug-iner...

sache aussi que la norme xhtml permet de faire des programme accessible aux handicapé mais toi je suppose que tu en
a rien a foutre qu'il y ai des aveugles et handicapés moteur qui se
servent du web...

En effet. Je préfère que les 90% non handicapés puissent accéder à
l'information plutôt que de les handicaper eux. Et si tu ne mets pas les
attributs correctement ça ne servira à rien à part à emmerder le monde.

[/HS]

rigoureusement la même chose.
http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40

tu verras que cela n'ets pas la meme chose, mais encore une fois faut lire la doc

La différence entre toi et moi c'est qu'après l'avoir lue j'arrive à la
conclusion que c'est bien la même chose pour le développement. Donc
selon le document que tu cites, donne moi une raison technique pour
laquelle il serait préférable d'utiliser echo au lieu de print, je suis
preneur, je suis certain que j'ai encore des vieux scripts avec des
"print" qui traînent.

parce pour toi que kk1 puisse balancer une variable en get alors que c un post que ton programme
recupere c'est pas une erreur???

Non. Je ne vois pas pourquoi ce serait une erreur. Qu'est-ce que ça peut
foutre ? Le danger c'est le contenu de la variable, pas son mode de
transmission.
Lis le thread initié par :
http://groups.google.com/groups?selmÂa7u2%24n6s%241%40news-reader5.wanadoo.fr
ça te sera des plus profitables, même si c'est un peu long.

avec la barre webdevelopper de mozilla on peut convertir les var
post en get donc commencer a faire ce qu'on veux....mais bon..

MDR :-) M'enfin !! Je sauvegarde ton code HTLM en fichier local, je
modifie ce que je veux veux, je recharge la copie locale et j'envoie
n'importe quoi, tout simplement. Depuis le temps qu'on le répète : rien
ni personne ne pourra m'empêcher dd'envoyer ce que je veux, quand je
veux, le nombre de fois que je voudrai à la seconde, à n'importe quel
script public. Rien qu'avec wget et CURL j'ai les outils pour le
scripter...

Moi j'ai changé une ligne et supprimé 3 lignes de code dans ma fonction
C'est ton probleme si tu fais du bricolage.

Là tu as manqué une occasion de te taire, vu qu'apparemment tu ne
connais même pas la notion de fonction. Comme même du temps de
register_globals en standard à "On" je n'utilisais JAMAIS directement
les variables mais que je les ai toujours filtrées par rapport à leur
contenu fonctionnel, je n'ai eut qu'à simplifier le code de ma fonction
de filtrage.

Cf
http://groups.google.com/groups?selm@4f96fa%240%24307%24636a15ce%40news.free.fr

Quand a ton post il ne fais que critiquer l'aide que j'ai apporté sur des point de detail
Quand je lis des âneries et que j'ai le temps, je les signale.

en en plus tu dis des conneries.
Tu parles en expert à ce sujet.

Surtout en ce qui concerne les normes.
Raison pour laquelle j'ai bien mis [HS] devant ces remarques.

Propose au lieu de critiquer.
Je n'ai rien à proposer, seulement à souligner tes âneries afin qu'elles

ne se propagent pas. Je n'utilise pas les sessions natives de PHP et je
ne les utiliserai pas tant qu'elles ne seront pas capables de gérer du
load balancing entre plusieurs machines frontales (1), j'utilise
toujours mes librairies perso développées du temps de PHP3.

(1) et ça va pas s'arranger avec l'arrivée de sqllite, cette affaire
là...


a++
JG

John Gallet wrote:

[HS] Norme ? Où ça ? Ah oui, standard de marché. Du temps où j'ai
appris

norme w3c, vas donc lire la doc puisque tu me le conseille si
joyeusement

C'est bien ce que je disais : standard de marché, pas norme. Mais
comme tu dis "ct" un détail de conversation.

Hum ... le HTML est bien une norme, c'est entre autres normalisé à l'ISO
(faire attention aux anglais qui utilisent le mots "standard" là où nous
utiliserions des fois "norme"). Il ne s'agit en tout cas pas d'un
standard du fait de l'utilisation commune mais bien d'une spécification
décrite par une entité régulatrice.

Quoiqu'il en soit je rejoins J.G. : écrire le HTML en majuscule ou
minuscule ne change rien. Les deux sont corrects et autorisés par les
recommandations. Écrire uniquement en minuscule est une mode récente
apparue avec la mode du XHTML (qui lui impose la minuscule), mais avant
on préconisait partout d'utiliser les majuscules sans que ça choque
personne. Je me permet d'ailleurs de faire remarquer que dans la
référence sur le sujet (les specs du W3C), de nombreuses balises sont
écrites en majuscules[1].

Ceci dit je vous suggère de déplacer les réponses au sujet du HTML dans
le groupe approprié, je crains que les sujets tels que l'accesssibilité
et le xhtml soit hautement sujets à débats et trolls (surtout trolls) et
qu'ils n'aient pas leur place ici.

[1] voir http://www.w3.org/TR/html4/intro/intro.html

parce pour toi que kk1 puisse balancer une variable en get alors
que c un post que ton programme recupere c'est pas une erreur???

Non. Je ne vois pas pourquoi ce serait une erreur. Qu'est-ce que ça
peut foutre ? Le danger c'est le contenu de la variable, pas son mode
de transmission.

J'irai même jusqu'à dire que le danger d'une donnée en réception vient
(presque) uniquement de son origine, pas de son mode de transmission.
Sauf si vous avez une très bonne raison $_POST $_COOKIE et $_GET ne
devraient pas être utilisés ($_REQUEST suffit). L'origine de ces
variables est la même, quelqu'un qui peut fournir la donnée avec un de
ces modes peut presque toujours la fournir avec les autres modes.
Bloquer en GET, POST ou COOKIE explicitement ne founri quasiment aucune
sécurité supplémentaire et ne peut que bloquer la portabilité ou
l'évolution des scripts.

Le seul cas que je vois c'est si vous voulez individualiser plusieurs
données de même nom qui viennent par plusieurs modes différents. Ceci
dit je me permet de douter de la pertinence d'avoir une telle architecture.

Je n'utilise pas les sessions natives
de PHP et je ne les utiliserai pas tant qu'elles ne seront pas
capables de gérer du load balancing entre plusieurs machines
frontales (1), j'utilise toujours mes librairies perso développées du
temps de PHP3.

Là je suis étonné tout de même.

- Il est possible d'écrire son propre gestionnaire de session
relativement simplement (y compris en PHP pur si on ne craint pas les
problèmes de perf). Ça revient aussi à utiliser une solution perso mais
ça reste tout de même plus confortable, en laissant PHP gérer tout ce
qu'il peut (y compris le pratique $_SESSION). Ça permet de plus de
pouvoir utiliser des libs externes sans avoir besoin de les réécrire
pour les faire passer par tes librairies de session perso.
À la limite adapter tes librairies perso pour en faire un backend de
session PHP4 ne doit pas prendre trop de temps.

- Indépendament de ça, la plupart des solutions de load balancing
arrivent à diriger un même utilisateur toujours vers le même frontal. Ça
permet justement de dupliquer le minimum de données possibles entre les
différentes machines, garder par exemple les caches temporaires et les
sessions propres à un utilisateur sur une seule machine.

À priori le fait d'avoir les données temporaires en local n'empêche pas
le load balancing, et le cas échéant il est simple de changer le backend
des sessions natives.
Il y a un problème supplémentaire que je ne vois pas ?


--
Eric Daspet
Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/

Re,

Il ne s'agit en tout cas pas d'un
standard du fait de l'utilisation commune mais bien d'une spécification
décrite par une entité régulatrice.

Nous sommes bien d'accord, au détail près que l'autorité régulatrice en
question a fait un pot-pourrit des existants pour pondre ladite spec,
d'où mon appelation de standard de fait.

Ceci dit je vous suggère de déplacer les réponses au sujet du HTML dans
le groupe approprié, je crains que les sujets tels que l'accesssibilité
et le xhtml soit hautement sujets à débats et trolls (surtout trolls) et
qu'ils n'aient pas leur place ici.

Je te rejoins, et je n'ai pas l'intention de troller longtemps sur ce
sujet là, il ne m'amuse pas. Comme je venais de me faire jeter par un
site "aux normes" qui m'est du coup inaccessible, ça m'a gavé et j'ai
fait un prix de gros avec le reste. J'aurais pas dû pour la partie html
dont on a clairemnt rien à battre ici.

Bloquer en GET, POST ou COOKIE explicitement ne founri quasiment aucune
sécurité supplémentaire et ne peut que bloquer la portabilité ou
l'évolution des scripts.

Je n'ai rien de mieux à en dire qu'aller dans ton sens en rappelant que
quand le graphiste change son éditeur favori aussi et donc l'attribut
METHOD des FORM peut changer aussi à la prochaine livraison... Déjà
vécu.

- Indépendament de ça, la plupart des solutions de load balancing
arrivent à diriger un même utilisateur toujours vers le même frontal.

Va dire ça à un altéon d'il y a deux ans qu'on rigole :-) Non justement
le problème est bien là. Tous les systèmes externes de load balancing ne
te permettent pas de le faire. Le load balancing sert à la fois de
répartition de charge et de redondance de fonctionnement (au pire si une
machine tombe tu tournes sur une seule patte le temps de la remettre
d'équerre).

Il y a un problème supplémentaire que je ne vois pas ?

Dans les cas de production que j'ai à gérer, on ne peut pas partir du
principe que la solution de load balancing est capable d'amener le même
client (navigateur) sur la même machine frontale pendant 10 minutes
d'affilée. Et c'est pas faute d'avoir essayé de trouver une solution.
Chez certains FAI, surtout si tu as une foultitude de proxys, le même
client peut changer d'adresse IP au cours de sa navigation (on a été
obligés de supprimer cette vérification). Ces machines frontales sont en
DMZ d'une part, et tu veux être insensible à la panne d'autre part donc
tout montage type NFS ou baie de disques partagée est interdit.

Bilan : tu ne peux pas écrire sur un file system commun, tu ne peux pas
écrire en mémoire, donc le problème est vite résolu, il ne te reste que
le SGBD pour stocker tes sessions utilisateur (lui même sur une autre
machine derrière le 2eme firewall et avec une base en réplication
esclave pour le hot backup).

Bref, ce n'est pas pour s'amuser, c'est parce que le besoin est bien là
dès que tu as une application haute disponibilité. L'effet positif est
que ça évite que $_SESSIONS ne devienne une poubelle.

Maintenant qu'on soit bien d'accord, ça tient en deux fonctions et
trois/quatre requêtes SQL, ça n'a rien de complexe. On faisait déjà ça
en php3 quand on avait rien de mieux. Je n'ai jamais vu de problèmes de
performances liés à cette partie là.

a++
JG

Le 04 May 2004 10:08:47 GMT, John Gallet <john.gallet@wanadoo.fr> écrivait:

4-Mieux vaux utiliser la methode post si tu utilise un formulaire.

[HS] Pourquoi ? C'est une norme ça aussi ? A part dans le cas de la
soumission d'un mot de passe pour éviter qu'il soit visible au dessus de
l'épaule de l'internaute par quelqu'un regardant son écran, ceci est une
affirmation gratuite.

Mieux vaux en effet, mais c'est pas une question de norme.
L'envoi d'un formulaire en GET ne pose *en général* pas de problème, mais en
pose en *particulier* si ton form contient un TEXTAREA, ou quelques
centaines de valeurs (si si ca existe quand on programme un panneau d'admin
comme un pied comme moi:-).

Un certain nombre de *navigateurs*, ne transmettent pas la totalité des
données :
si elles sont passées en GET
si le volume est trop important

Il y a un débordement de buffer (invisible) et le navigateur passe alors le
contenu des variables à la trappe et ton script serveur n'a rien à se mettre
sous la dent .

Hors c'est un cas toujours possible si tu as un textarea dans ton formulaire
puisqu'il n'y a pas de possibilité, sauf erreur, d'en limiter le contenu
coté client, donc de connaitre à priori le volume d'infos transmises.

Et ca c'est pas une affirmation gratuite;-) J'en parle par expérience pour
m'être arraché les cheveux il y a quelques années sur ce problème de prime
abord incompréhensible (à moins de tracer les requêtes ce qui ne relevait
pas de mes compétences à l'époque et pas tellement plus aujourd'hui:-).

A l'époque d'ailleurs je n'ai du trouver que deux ou trois post au niveau
mondial parlant de ce problème.
Mais avec le contenu de 2 ou 3 pages A4 dans un textarea le problème est
assez facile à reproduire (quoi que ce problème est peut-être corrigé dans
les nouvelles versions de navigateurs, mais j'en doute pour certains...et
de toute manière ca ne représente pas la majorité du parc déployé). De
mémoire selon les navigateurs le débordement se produisait entre 12 et 30Ko,
pour d'autres ca ne posait aucun problème..

C'est à mon bon avis raison suffisante pour *systématiquement* passer tous
ses form en POST ce qui ne pose aucun problème car comme tu le fais
remarquer assez souvent on se fout bien par quelle méthode sont acheminées
les données.


Cdlt,
Stéph'.

--
AcroDict : Dictionnaire francophone des acronymes informatiques
<URL:http://www.teaser.fr/~spineau/acrodict/index.htm>
PHP Page : Script PHP3 Gratuits (Forum, Gestionnaires BDD, etc..)
<URL:http://steph.pineau.free.fr/php/index.php>

La différence entre toi et moi c'est qu'après l'avoir lue j'arrive à la

Tu veux un cours d'anglais?

MDR :-) M'enfin !! Je sauvegarde ton code HTLM en fichier local, je

C'est bien tu es un grand garçon
n'empêche que t'a aucun savoir vivre et puisque tu as du temps pour
répondre tu aurai aussi pu prendre le temps de parler aimablement

Là tu as manqué une occasion de te taire, vu qu'apparemment tu ne
connais même pas la notion de fonction. Comme même du temps de

Je vois pas ce qui te fais dire ca je te trouve présomptueux et
prétentieux alors gardes tes distances tu seras mignon.

Quand je lis des âneries
mais arretes toi la... quand on li ce qu'il y a plus bas que tu prefere

faire pour les gens valide ca prouve bien que les aneries c pas moi qui
les dis.

Tu parles en expert à ce sujet.
Tout autant que toi.

Raison pour laquelle j'ai bien mis [HS] devant ces remarques.
quelle subtilité

Je n'ai rien à proposer, seulement à souligner tes âneries afin
alors fermes ta gueule si t'a rien a proposer

PHP et je ne les utiliserai pas tant qu'elles ne seront pas capables de
gérer du load balancing entre plusieurs machines frontales (1),
j'utilise toujours mes librairies perso développées du temps de PHP3.

C pas ce qu'on demande, si le gars veux utiliser les sessions et les
formulaire et qu'il a des soucis le but c'est l'aider.
Toi tu n'est qu'un pauvre intégriste de merde qui se la pètes technique
et qui denigre les personne handicapées.
T'es un connard et j'espère que tu créveras seul et désespéré et
surtout bientôt.

Loquace, l'âne bâté qui porte bien son nom !!

La différence entre toi et moi c'est qu'après l'avoir lue j'arrive à la

Tu veux un cours d'anglais?

ouais là j'en veux bien un .... on peut tergiverser lgtps sur combien de
diplomes d'anglais on a , notre niveau de bilinguisme, mais moi j'arrive à
la même conclusion que JG ...

"There is a difference between the two, but speed-wise it should be
irrelevant which one you use"
--> il y a une différence entre les 2, mais pas significative au niveau de
la vitesse.

"echo is marginally faster "
--> je traduis ? d'ailleurs la suite de la phrase est explicite

donc je vais aussi te reposer la question : quelle différence vois-tu entre
les 2 fonctions (pour l'affichage s'entend)? (du moins dans ton article, qui
soit dit en passant
n'apporte rien de neuf)

@++
Pimousse

en ce qui concerne l'affichage je suis bien d'accord.
Mais il ne faut pas dire que c pareil.
Ce n'est pas là la source du conflit.
Si tu relis plus haut, c une critique d'une aide que j'ai fournie en me
prenant systématiquement pour un con.
Quand j'aide c de façon cordiale et par rapport a ce que je sais.
On peut pas tout savoir cela n'est donc pas une raison pour me
parler sur le ton dont monsieur JG l'a fait.
Je savais pas que ici c'était réservé a l'élite, le fleuron du php.
Je n'ai que 4 ou 5 ans d'expérience et php c un des premier que j'ai
appris.
Voila, maintenant si apporter son aide est sujet a polémique, dans ce cas...
Surtout quand on aborde des points techniques qui n'ont rien a voir avec
la question de depart et ignorant meme jusqu'a la personne qui l'a posée.
Quelle incorrection, je suis vraiment en rogne. Ca se trouve c'est juste
pour un formulaire de site perso en plus donc il n'y aurait rien de
dramatique.
Seb