Problème de session sur Chrome.

[Jean Francois Ortolo]

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.

Ce formulaire se trouve à l'url suivante :

https://www.pronostics-courses.fr/php/contact/contact.php

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

[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

Post by Jean Francois Ortolo
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.
https://www.pronostics-courses.fr/php/contact/contact.php
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.
"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]

Post by 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

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

Post by Jean Francois Ortolo
Bonjour yotta
Problème résolu.
A+.
Jean François Ortolo

[Jean Francois Ortolo]

Post by 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

Bonjour

Je n'alimente pas vos querelles.

A+.

Jean François Ortolo

[Jean Francois Ortolo]

Post by 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

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

[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.

Post by 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
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