J'ai un problème de session qui se produit sous Chrome, pas sous Firefox.
La variable de session $_SESSION['tmp_reponse'] est alimentée au
milieu du script de formulaire de contact de mon site, avec la réponse
au captcha qui est instancié juste avant.
Cette variable de session est lue en tout début du script, et est
comparée avec la réponse donnée par le visiteur.
Le formulaire est est en mode POST, la variable post est correcte,
mais la variable de session n'est pas correcte.
Ceci systématiquement sous Chrome.
Sous Firefox, tout est correct.
L'url "action" de la balise <form" est bien correcte en https.
Est-ce que celà a quelque chose à voir avec avec le mode prerender de
Chrome ?
La variable de session ( sous Chrome ), est comme si elle avait été
alimentée correctement mais elle est fausse.
C'est-à-dire, avec une seule lettre minuscule.
Il semble que cette variable de session soit alimentée deux fois au
moins, éventuellement suite à un problème de Chrome. ( ou un problème de
prerender ).
Je suis sous Linux Fedora version 22 64 bits.
'uname -a ' donne :
"Linux pha75-5-82-225-74-10.fbx.proxad.net 4.1.3-201.fc22.x86_64 #1 SMP
Wed Jul 29 19:50:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux"
Mon navigateur Chrome est : "Version 44.0.2403.130 (64-bit)".
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
yotta
J'ai lâché chrome...les extensions étaient tout le temps, tout le temps obsolètes.
puis je trouve qu'il bouffe plus avec apache et l'ide
c'est joli de rêver à un monde meilleur...encore faut il des bonnes volontés... t'as une version portable de chrome ? t'es alerté tout le temps qu'il y a une pseudo maj ?
ça t'arrive d'aller sur play store ? t'as un téléphone android ? un mail gmail ? tu me diras on devrait pouvoir télécharger une apk via firefox...non ?
sinon pour ton script j'aime pas parler de méthode comme ça...à 4 mains un bon blabla ça le fait...
tu veux pas poster ton script...t'es scripts ?
yotta
"Jean Francois Ortolo" a écrit dans le message de news:55caf122$0$32626$
Bonjour
J'ai un problème de session qui se produit sous Chrome, pas sous Firefox.
La variable de session $_SESSION['tmp_reponse'] est alimentée au milieu du script de formulaire de contact de mon site, avec la réponse au captcha qui est instancié juste avant.
Cette variable de session est lue en tout début du script, et est comparée avec la réponse donnée par le visiteur.
Le formulaire est est en mode POST, la variable post est correcte, mais la variable de session n'est pas correcte.
Ceci systématiquement sous Chrome.
Sous Firefox, tout est correct.
L'url "action" de la balise <form" est bien correcte en https.
Est-ce que celà a quelque chose à voir avec avec le mode prerender de Chrome ?
La variable de session ( sous Chrome ), est comme si elle avait été alimentée correctement mais elle est fausse.
C'est-à-dire, avec une seule lettre minuscule.
Il semble que cette variable de session soit alimentée deux fois au moins, éventuellement suite à un problème de Chrome. ( ou un problème de prerender ).
Je suis sous Linux Fedora version 22 64 bits.
'uname -a ' donne : "Linux pha75-5-82-225-74-10.fbx.proxad.net 4.1.3-201.fc22.x86_64 #1 SMP Wed Jul 29 19:50:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux"
Mon navigateur Chrome est : "Version 44.0.2403.130 (64-bit)".
Est-ce un bug de Chrome ?
Merci beaucoup de votre aide.
Respectueusement.
Jean François Ortolo
J'ai lâché chrome...les extensions étaient tout le temps, tout le temps
obsolètes.
puis je trouve qu'il bouffe plus avec apache et l'ide
c'est joli de rêver à un monde meilleur...encore faut il des bonnes
volontés...
t'as une version portable de chrome ? t'es alerté tout le temps qu'il y a
une
pseudo maj ?
ça t'arrive d'aller sur play store ? t'as un téléphone android ? un mail
gmail ?
tu me diras on devrait pouvoir télécharger une apk via firefox...non ?
sinon pour ton script j'aime pas parler de méthode comme ça...à 4 mains
un bon blabla ça le fait...
tu veux pas poster ton script...t'es scripts ?
yotta
"Jean Francois Ortolo" <ortolo.jeanfrancois@free.fr> a écrit dans le message
de news:55caf122$0$32626$426a34cc@news.free.fr...
Bonjour
J'ai un problème de session qui se produit sous Chrome, pas sous
Firefox.
La variable de session $_SESSION['tmp_reponse'] est alimentée au milieu
du script de formulaire de contact de mon site, avec la réponse au captcha
qui est instancié juste avant.
Cette variable de session est lue en tout début du script, et est
comparée avec la réponse donnée par le visiteur.
Le formulaire est est en mode POST, la variable post est correcte, mais
la variable de session n'est pas correcte.
Ceci systématiquement sous Chrome.
Sous Firefox, tout est correct.
L'url "action" de la balise <form" est bien correcte en https.
Est-ce que celà a quelque chose à voir avec avec le mode prerender de
Chrome ?
La variable de session ( sous Chrome ), est comme si elle avait été
alimentée correctement mais elle est fausse.
C'est-à-dire, avec une seule lettre minuscule.
Il semble que cette variable de session soit alimentée deux fois au
moins, éventuellement suite à un problème de Chrome. ( ou un problème de
prerender ).
Je suis sous Linux Fedora version 22 64 bits.
'uname -a ' donne :
"Linux pha75-5-82-225-74-10.fbx.proxad.net 4.1.3-201.fc22.x86_64 #1 SMP
Wed Jul 29 19:50:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux"
Mon navigateur Chrome est : "Version 44.0.2403.130 (64-bit)".
J'ai lâché chrome...les extensions étaient tout le temps, tout le temps obsolètes.
puis je trouve qu'il bouffe plus avec apache et l'ide
c'est joli de rêver à un monde meilleur...encore faut il des bonnes volontés... t'as une version portable de chrome ? t'es alerté tout le temps qu'il y a une pseudo maj ?
ça t'arrive d'aller sur play store ? t'as un téléphone android ? un mail gmail ? tu me diras on devrait pouvoir télécharger une apk via firefox...non ?
sinon pour ton script j'aime pas parler de méthode comme ça...à 4 mains un bon blabla ça le fait...
tu veux pas poster ton script...t'es scripts ?
yotta
"Jean Francois Ortolo" a écrit dans le message de news:55caf122$0$32626$
Bonjour
J'ai un problème de session qui se produit sous Chrome, pas sous Firefox.
La variable de session $_SESSION['tmp_reponse'] est alimentée au milieu du script de formulaire de contact de mon site, avec la réponse au captcha qui est instancié juste avant.
Cette variable de session est lue en tout début du script, et est comparée avec la réponse donnée par le visiteur.
Le formulaire est est en mode POST, la variable post est correcte, mais la variable de session n'est pas correcte.
Ceci systématiquement sous Chrome.
Sous Firefox, tout est correct.
L'url "action" de la balise <form" est bien correcte en https.
Est-ce que celà a quelque chose à voir avec avec le mode prerender de Chrome ?
La variable de session ( sous Chrome ), est comme si elle avait été alimentée correctement mais elle est fausse.
C'est-à-dire, avec une seule lettre minuscule.
Il semble que cette variable de session soit alimentée deux fois au moins, éventuellement suite à un problème de Chrome. ( ou un problème de prerender ).
Je suis sous Linux Fedora version 22 64 bits.
'uname -a ' donne : "Linux pha75-5-82-225-74-10.fbx.proxad.net 4.1.3-201.fc22.x86_64 #1 SMP Wed Jul 29 19:50:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux"
Mon navigateur Chrome est : "Version 44.0.2403.130 (64-bit)".
Est-ce un bug de Chrome ?
Merci beaucoup de votre aide.
Respectueusement.
Jean François Ortolo
Jean Francois Ortolo
Le 12/08/2015 18:47, yotta a écrit :
J'ai lâché chrome...les extensions étaient tout le temps, tout le temps obsolètes.
puis je trouve qu'il bouffe plus avec apache et l'ide
c'est joli de rêver à un monde meilleur...encore faut il des bonnes volontés... t'as une version portable de chrome ? t'es alerté tout le temps qu'il y a une pseudo maj ?
ça t'arrive d'aller sur play store ? t'as un téléphone android ? un mail gmail ? tu me diras on devrait pouvoir télécharger une apk via firefox...non ?
sinon pour ton script j'aime pas parler de méthode comme ça...à 4 mains un bon blabla ça le fait...
tu veux pas poster ton script...t'es scripts ?
yotta
Bonjour yotta
Problème résolu.
A+.
Jean François Ortolo
Le 12/08/2015 18:47, yotta a écrit :
J'ai lâché chrome...les extensions étaient tout le temps, tout le temps
obsolètes.
puis je trouve qu'il bouffe plus avec apache et l'ide
c'est joli de rêver à un monde meilleur...encore faut il des bonnes
volontés...
t'as une version portable de chrome ? t'es alerté tout le temps qu'il y
a une
pseudo maj ?
ça t'arrive d'aller sur play store ? t'as un téléphone android ? un mail
gmail ?
tu me diras on devrait pouvoir télécharger une apk via firefox...non ?
sinon pour ton script j'aime pas parler de méthode comme ça...à 4 mains
un bon blabla ça le fait...
J'ai lâché chrome...les extensions étaient tout le temps, tout le temps obsolètes.
puis je trouve qu'il bouffe plus avec apache et l'ide
c'est joli de rêver à un monde meilleur...encore faut il des bonnes volontés... t'as une version portable de chrome ? t'es alerté tout le temps qu'il y a une pseudo maj ?
ça t'arrive d'aller sur play store ? t'as un téléphone android ? un mail gmail ? tu me diras on devrait pouvoir télécharger une apk via firefox...non ?
sinon pour ton script j'aime pas parler de méthode comme ça...à 4 mains un bon blabla ça le fait...
tu veux pas poster ton script...t'es scripts ?
yotta
Bonjour yotta
Problème résolu.
A+.
Jean François Ortolo
yotta
ok mais c'était quoi ? un ; un seul = à la condition ou 2 = c'était pas un session_destroy()...sinon firefox aurait pas donner...
la sérialisation peut être ?
faissant profiter tout le monde qu'on soit meilleurs tous ensembles !
yotta
"Jean Francois Ortolo" a écrit dans le message de news:55cb79c7$0$3165$
Bonjour yotta
Problème résolu.
A+.
Jean François Ortolo
ok mais c'était quoi ? un ; un seul = à la condition ou 2 =
c'était pas un session_destroy()...sinon firefox aurait pas donner...
la sérialisation peut être ?
faissant profiter tout le monde qu'on soit meilleurs tous ensembles !
yotta
"Jean Francois Ortolo" <ortolo.jeanfrancois@free.fr> a écrit dans le message
de news:55cb79c7$0$3165$426a74cc@news.free.fr...
ok mais c'était quoi ? un ; un seul = à la condition ou 2 = > c'était pas un session_destroy()...sinon firefox aurait pas donner...
la sérialisation peut être ?
faissant profiter tout le monde qu'on soit meilleurs tous ensembles !
yotta
Bonjour
Je n'alimente pas vos querelles.
A+.
Jean François Ortolo
Jean Francois Ortolo
Le 12/08/2015 19:05, yotta a écrit :
ok mais c'était quoi ? un ; un seul = à la condition ou 2 = > c'était pas un session_destroy()...sinon firefox aurait pas donner...
la sérialisation peut être ?
faissant profiter tout le monde qu'on soit meilleurs tous ensembles !
yotta
Pardon
Bonjour Monsieur
Le problème ( semble-t-il ), était du au fait que Chrome déclenchait le script du formulaire en deux fois :
1- Les variables $_POST ne sont pas alimentées ( mode "prerender" théoriquement ), mais le code php est lu est exécuté. La variable de session "reponse" peut éventuellement être affectée.
2- Mode "visible" : Le code php semble être re-exécuté, les variables $_POST sont disponibles, les variables de session peuvent éventuellement être réécrites.
L'astuce, consiste à n'écrire la variable de session que si la variable $_POST est alimentées et non vide.
Celà correspond au mode "visible", où le nouveau catcha ( qui sera affecté à la variable de session ), est fixé et ne change plus.
Croisons les doigts, pour que ces variables $_POST restent non alimentées en mode "prerender", mais comme celà dépend du W3C ...
Respectueusement.
Jean François Ortolo
Le 12/08/2015 19:05, yotta a écrit :
ok mais c'était quoi ? un ; un seul = à la condition ou 2 = >
c'était pas un session_destroy()...sinon firefox aurait pas donner...
la sérialisation peut être ?
faissant profiter tout le monde qu'on soit meilleurs tous ensembles !
yotta
Pardon
Bonjour Monsieur
Le problème ( semble-t-il ), était du au fait que Chrome déclenchait
le script du formulaire en deux fois :
1- Les variables $_POST ne sont pas alimentées ( mode "prerender"
théoriquement ), mais le code php est lu est exécuté. La variable de
session "reponse" peut éventuellement être affectée.
2- Mode "visible" : Le code php semble être re-exécuté, les variables
$_POST sont disponibles, les variables de session peuvent éventuellement
être réécrites.
L'astuce, consiste à n'écrire la variable de session que si la
variable $_POST est alimentées et non vide.
Celà correspond au mode "visible", où le nouveau catcha ( qui sera
affecté à la variable de session ), est fixé et ne change plus.
Croisons les doigts, pour que ces variables $_POST restent non
alimentées en mode "prerender", mais comme celà dépend du W3C ...
ok mais c'était quoi ? un ; un seul = à la condition ou 2 = > c'était pas un session_destroy()...sinon firefox aurait pas donner...
la sérialisation peut être ?
faissant profiter tout le monde qu'on soit meilleurs tous ensembles !
yotta
Pardon
Bonjour Monsieur
Le problème ( semble-t-il ), était du au fait que Chrome déclenchait le script du formulaire en deux fois :
1- Les variables $_POST ne sont pas alimentées ( mode "prerender" théoriquement ), mais le code php est lu est exécuté. La variable de session "reponse" peut éventuellement être affectée.
2- Mode "visible" : Le code php semble être re-exécuté, les variables $_POST sont disponibles, les variables de session peuvent éventuellement être réécrites.
L'astuce, consiste à n'écrire la variable de session que si la variable $_POST est alimentées et non vide.
Celà correspond au mode "visible", où le nouveau catcha ( qui sera affecté à la variable de session ), est fixé et ne change plus.
Croisons les doigts, pour que ces variables $_POST restent non alimentées en mode "prerender", mais comme celà dépend du W3C ...
Respectueusement.
Jean François Ortolo
Jean Francois Ortolo
J'ajoute...
Il est possible ( et semble -t-il désormais nécessaire pour un formulaire post ), de mettre les variables post en session quand elles sont alimentées ( (isset($_POST['var'])) et (!(empty($_POST['var'])) ), puis de les relire à partir des variables de session quand elles ne sont plus alimentées. (!isset($_POST['var']))
Il est parfaitement possible d'automatiser celà dans un script séparé, avec des variables globales.
A charge ( quand de nouvelles versions de PHP n'autoriseront plus les variables globales ), de mettre celà dans une fonction rendant une array de ces variables
A ce propos, c'est une véritable question pour moi :
Est-il question, parmi les développeurs du langage PHP, d'interdire dans un futur proche ou lointain, les variables globales ?
Merci beaucoup de vos réponses.
Respectueusement.
Jean François Ortolo
J'ajoute...
Il est possible ( et semble -t-il désormais nécessaire pour un
formulaire post ), de mettre les variables post en session quand elles
sont alimentées ( (isset($_POST['var'])) et (!(empty($_POST['var'])) ),
puis de les relire à partir des variables de session quand elles ne sont
plus alimentées. (!isset($_POST['var']))
Il est parfaitement possible d'automatiser celà dans un script
séparé, avec des variables globales.
A charge ( quand de nouvelles versions de PHP n'autoriseront plus les
variables globales ), de mettre celà dans une fonction rendant une array
de ces variables
A ce propos, c'est une véritable question pour moi :
Est-il question, parmi les développeurs du langage PHP, d'interdire
dans un futur proche ou lointain, les variables globales ?
Il est possible ( et semble -t-il désormais nécessaire pour un formulaire post ), de mettre les variables post en session quand elles sont alimentées ( (isset($_POST['var'])) et (!(empty($_POST['var'])) ), puis de les relire à partir des variables de session quand elles ne sont plus alimentées. (!isset($_POST['var']))
Il est parfaitement possible d'automatiser celà dans un script séparé, avec des variables globales.
A charge ( quand de nouvelles versions de PHP n'autoriseront plus les variables globales ), de mettre celà dans une fonction rendant une array de ces variables
A ce propos, c'est une véritable question pour moi :
Est-il question, parmi les développeurs du langage PHP, d'interdire dans un futur proche ou lointain, les variables globales ?
Merci beaucoup de vos réponses.
Respectueusement.
Jean François Ortolo
yotta
après un $_POST il faut en rester à une variable du type $_SESSION[''toto'] idem pour un $_GET session_start() session_destroy() unset je ne parlerais pas d'AJAX, JQUERY...and Co...de la sérialisation de l'écriture serveur "depuis" le "poste client"...
s'assuré d'un id quand même on ne sait jamais...un php_info() quoi.
je suis sous PHP 5.4.41 VC9
à priori les mises à jour de PHP n'ont pas nettoyé les data center de tous ces gigas octets pour une simple question sur php et dont on n'a pas forcément la réponse en ligne...
il m'ait arrivé de sauvegarder des pages (enregistré sous) qui faisaient plusieurs mégas ! (sans vidéo)
je ne suis pas un "guru" en PHP, ni en sécurité informatique...mais pour l'avenir du...code...du NET...lorsque je vois qu'on te propose aujourd'hui 1To pour une BAL et qu'on te refuse l'accès à ta BAL parce que t'as changé de machine... ça pue grave...
a+
yotta
Nota : La syntaxe SQL et la promenad du curseur datent des années 70.
"Jean Francois Ortolo" a écrit dans le message de news:55cdb22b$0$2973$
J'ajoute...
Il est possible ( et semble -t-il désormais nécessaire pour un formulaire post ), de mettre les variables post en session quand elles sont alimentées ( (isset($_POST['var'])) et (!(empty($_POST['var'])) ), puis de les relire à partir des variables de session quand elles ne sont plus alimentées. (!isset($_POST['var']))
Il est parfaitement possible d'automatiser celà dans un script séparé, avec des variables globales.
A charge ( quand de nouvelles versions de PHP n'autoriseront plus les variables globales ), de mettre celà dans une fonction rendant une array de ces variables
A ce propos, c'est une véritable question pour moi :
Est-il question, parmi les développeurs du langage PHP, d'interdire dans un futur proche ou lointain, les variables globales ?
Merci beaucoup de vos réponses.
Respectueusement.
Jean François Ortolo
après un $_POST il faut en rester à une variable du type $_SESSION[''toto']
idem pour un $_GET
session_start()
session_destroy()
unset
je ne parlerais pas d'AJAX, JQUERY...and Co...de la sérialisation de
l'écriture
serveur "depuis" le "poste client"...
s'assuré d'un id quand même on ne sait jamais...un php_info() quoi.
je suis sous PHP 5.4.41 VC9
à priori les mises à jour de PHP n'ont pas nettoyé les data center de tous
ces gigas octets pour une simple question sur php et dont on n'a pas
forcément la réponse en ligne...
il m'ait arrivé de sauvegarder des pages (enregistré sous) qui faisaient
plusieurs
mégas ! (sans vidéo)
je ne suis pas un "guru" en PHP, ni en sécurité informatique...mais pour
l'avenir
du...code...du NET...lorsque je vois qu'on te propose aujourd'hui 1To pour
une
BAL et qu'on te refuse l'accès à ta BAL parce que t'as changé de machine...
ça pue grave...
a+
yotta
Nota : La syntaxe SQL et la promenad du curseur datent des années 70.
"Jean Francois Ortolo" <ortolo.jeanfrancois@free.fr> a écrit dans le message
de news:55cdb22b$0$2973$426a74cc@news.free.fr...
J'ajoute...
Il est possible ( et semble -t-il désormais nécessaire pour un
formulaire post ), de mettre les variables post en session quand elles
sont alimentées ( (isset($_POST['var'])) et (!(empty($_POST['var'])) ),
puis de les relire à partir des variables de session quand elles ne sont
plus alimentées. (!isset($_POST['var']))
Il est parfaitement possible d'automatiser celà dans un script séparé,
avec des variables globales.
A charge ( quand de nouvelles versions de PHP n'autoriseront plus les
variables globales ), de mettre celà dans une fonction rendant une array
de ces variables
A ce propos, c'est une véritable question pour moi :
Est-il question, parmi les développeurs du langage PHP, d'interdire dans
un futur proche ou lointain, les variables globales ?
après un $_POST il faut en rester à une variable du type $_SESSION[''toto'] idem pour un $_GET session_start() session_destroy() unset je ne parlerais pas d'AJAX, JQUERY...and Co...de la sérialisation de l'écriture serveur "depuis" le "poste client"...
s'assuré d'un id quand même on ne sait jamais...un php_info() quoi.
je suis sous PHP 5.4.41 VC9
à priori les mises à jour de PHP n'ont pas nettoyé les data center de tous ces gigas octets pour une simple question sur php et dont on n'a pas forcément la réponse en ligne...
il m'ait arrivé de sauvegarder des pages (enregistré sous) qui faisaient plusieurs mégas ! (sans vidéo)
je ne suis pas un "guru" en PHP, ni en sécurité informatique...mais pour l'avenir du...code...du NET...lorsque je vois qu'on te propose aujourd'hui 1To pour une BAL et qu'on te refuse l'accès à ta BAL parce que t'as changé de machine... ça pue grave...
a+
yotta
Nota : La syntaxe SQL et la promenad du curseur datent des années 70.
"Jean Francois Ortolo" a écrit dans le message de news:55cdb22b$0$2973$
J'ajoute...
Il est possible ( et semble -t-il désormais nécessaire pour un formulaire post ), de mettre les variables post en session quand elles sont alimentées ( (isset($_POST['var'])) et (!(empty($_POST['var'])) ), puis de les relire à partir des variables de session quand elles ne sont plus alimentées. (!isset($_POST['var']))
Il est parfaitement possible d'automatiser celà dans un script séparé, avec des variables globales.
A charge ( quand de nouvelles versions de PHP n'autoriseront plus les variables globales ), de mettre celà dans une fonction rendant une array de ces variables
A ce propos, c'est une véritable question pour moi :
Est-il question, parmi les développeurs du langage PHP, d'interdire dans un futur proche ou lointain, les variables globales ?
