Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Je détecte automatiquement si Javascript est activé

26 views
Skip to first unread message

Jean Francois Ortolo

unread,
Jun 19, 2012, 6:15:02 AM6/19/12
to


Bonjour

J'ai apporté une modification à mon site www.pronostics-courses.fr

Maintenant, quand Javascript n'est pas activé, un message s'affiche
en haut de l'écran, pour demander à activer Javascript.

Quand Javascript est activé, et qu'il n'y a eu aucune page de chargée
depuis plus de 30 secondes, le script Javascript inclus dans
pratiquement toutes les pages, efface sur le site, le fichier éventuel
caractéristique de l'adresse ip du visiteur, après avoir reconnu que la
variable de session js date de plus de 30 secondes, ou qu'elle n'existe
pas, puis affecte la variable de session js avec la valeur de la
fonction time() ( qui donne le nombre de secondes depuis le 1er Janvier
1970 je crois ), puis recharge la page, après avoir écrit sur le site,
le fichier caractéristique de l'adresse ip du visiteur.

Ce fichier, me sert essentiellement, à savoir si c'est le premier
chargement, ou le second.

Si le fichier caractéristique existe, et que la variable de session
js date de moins de 30 secondes, cette variable est mis à jour avec la
fonction time(), et il n'y a pas de rechargement de la page.

Celà prouve, que Javascript est activé.

Si le fichier caractéristique n'existe pas, c'est le premier
chargement, donc même chose qu'au début.

Si Javascript n'existe pas, le deuxième script qui crée le fichier
caractéristique, et met à jour la variable de session js, ne s'exécute
pas, et le script php inclus dans les pages du site, détecte que la
variable de session js, n'existe pas, ou est plus ancienne que 30 secondes.

Celà indique que Javascript est désactivé, ainsi le script inclus
dans les pages, affiche le message suggérant d'activer Javascript.

Pour alimenter la variable de session js, et créer le fichier
caractéristique, le script qui le fait, est lancé en Javascript par le
script inclus dans les pages, ce qui fait que ce deuxième script, ne
crée pas le fichier caractéristique, et ne met pas à jour la variable de
session js, si Javascript est désactivé.

Mon site fonctionne, mais le fait que je sois obligé, pour savoir si
c'est le premier chargement ou le deuxième, d'avoir un fichier
caractéristique du visiteur ( par l'adresse ip ), me semble avoir des
limitations, dans le cas ou l'adresse ip cliente, change à chaque
chargement de page.

C'est peut-être le cas du FAI AOL, ou de certaines connexions internet.

Je ne vois pas, comment détecter si c'est le premeir chargement ou le
deuxième, sans ce fichier caractéristique.

Je ne sais pas, si quand l'adresse ip cliente change, il est possible
au navigateur client, de mémoriser un identifiant de session, et si le
serveur, constatant que l'adresse ip change, va pouvoir aussi, méoriser
les variables de session.

Merci beaucoup de me le dire.

J'aurais besoin, que vous me disiez, si mon site fonctionne bien,
même dans ces conditions ( ce qui est peu probable ), et si celà ne
fonctionne pas, quel est son comportement.

Mon site, si Javascript est activé, détecte aussi si les cookies sont
acceptés, et sinon, affiche une fenêtre popup en Javascript, suggérant
d'accepter les cookies.

Pour l'instant, ces deux fonctionnalités ( Javascript et les cookies
), ne sont pas strictement nécessaires au fonctionnement de mon site.

Cependant, dans l'optique de mettre en place un module d'inscription
et d'authentification des visiteurs, pour des fonctionnalités pour
l'instant gratuites ( envoi automatique quotidien de mes pronostics de
quinté ), il y aura nécessité pour que les visiteurs soient authentifiés
que Javascript soit activé,et les cookies permis.

En dehors des spécificités du langage PHP, j'aurais simplement
besoin, que vous me disiez, si mon site fonctionne correctement, dans
toutes les conditions.

Merci beaucoup de vos réponses.

Jean François Ortolo


Jean Francois Ortolo

unread,
Jun 19, 2012, 6:21:51 AM6/19/12
to


Rebonjour

Je vous prie de m'excuser.

J'ai fait une erreur dans la description de l'algorithme utilisé pour
détecter si Javascript st activé ou non.

Je corrige ci-dessous, l'erreur.

Bien amicalement.

Jean François Ortolo


Le 19/06/2012 12:15, Jean Francois Ortolo a écrit :
>
>
> Bonjour
>
> J'ai apporté une modification à mon site www.pronostics-courses.fr
>
> Maintenant, quand Javascript n'est pas activé, un message s'affiche
> en haut de l'écran, pour demander à activer Javascript.
>
> Quand Javascript est activé, et qu'il n'y a eu aucune page de chargée
> depuis plus de 30 secondes, le script Javascript inclus dans
> pratiquement toutes les pages, lance en mode Ajax, un autre script php, qui efface sur le site, le fichier éventuel
> caractéristique de l'adresse ip du visiteur, après avoir reconnu que la
> variable de session js date de plus de 30 secondes, ou qu'elle n'existe
> pas, puis affecte la variable de session js avec la valeur de la
> fonction time() ( qui donne le nombre de secondes depuis le 1er Janvier
> 1970 je crois ), puis recharge la page en Javascript, après avoir écrit sur le site,
> le fichier caractéristique de l'adresse ip du visiteur.
>

> Le fichier inclus lançant le script en Javascript, reçoit une
> réponse en mode synchrone de ce script, lui indiquant le diagnostic
> fait par le script lancé en Javascript.

> Le fichier caractéristique, me sert essentiellement, à savoir si c'est le premier
> chargement, ou le second.
>
> Si le fichier caractéristique existe, et que la variable de session
> js date de moins de 30 secondes, cette variable est mis à jour avec la
> fonction time(), et il n'y a pas de rechargement de la page.
>
> Celà prouve, que Javascript est activé.
>
> Si le fichier caractéristique n'existe pas, c'est le premier
> chargement, donc même chose qu'au début.
>
> Si Javascript n'existe pas, le script lancé en Javascript, qui crée le fichier

Olivier Miakinen

unread,
Jun 21, 2012, 6:12:46 AM6/21/12
to
Bonjour,

Le 19/06/2012 12:15, Jean Francois Ortolo a écrit :
>
> J'ai apporté une modification à mon site www.pronostics-courses.fr
>
> Maintenant, quand Javascript n'est pas activé, un message s'affiche
> en haut de l'écran, pour demander à activer Javascript.

Ok. Le site ne fonctionne pas du tout sans JavaScript, même en mode
dégradé ? Dans ce cas, oui, ça me semble bien de prévenir qu'il est
indispensable.

> Quand Javascript est activé, et qu'il n'y a eu aucune page de chargée
> depuis plus de 30 secondes, le script Javascript inclus dans
> pratiquement toutes les pages, efface sur le site, le fichier éventuel
> caractéristique de l'adresse ip du visiteur [...]
>
> Ce fichier, me sert essentiellement, à savoir si c'est le premier
> chargement, ou le second.

Quitte à imposer que JavaScript soit actif, autant imposer aussi que
les cookies le soient également, ça me semble bien plus pertinent que
l'adresse IP.

En effet, d'une part l'adresse IP peut changer en cours de navigation
web, par exemple si l'utilisateur a une adresse obtenue par DHCP et
que cette adresse change, mais inversement tu peux avoir des centaines
d'utilisateurs différents avec la même adresse IP s'ils passent tous
par le même proxy.

Pour quelle raison as-tu besoin de distinguer le premier chargement du
second ? Quelques cas de figure :
1) J'ai déjà une fenêtre ouverte sur ton site depuis mon SeaMonkey, et
j'ouvre une deuxième fenêtre par Ctrl+N. Est-ce un premier chargement
ou un second ?
2) J'ai là encore une première fenêtre ouverte depuis mon SeaMonkey, et
j'en ouvre une autre depuis Firefox, Opera ou Internet Explorer. Même
question.
3) Enfin, j'ai une première fenêtre ouverte, je quitte mon navigateur et
je le relance. Je reviens sur ton site. Même question. La réponse
change-t-elle selon que j'aille directement sur la page que je venais
de quitter ou que je repasse par la page d'accueil ?

> Mon site fonctionne, mais le fait que je sois obligé, pour savoir si
> c'est le premier chargement ou le deuxième, d'avoir un fichier
> caractéristique du visiteur ( par l'adresse ip ), me semble avoir des
> limitations, dans le cas ou l'adresse ip cliente, change à chaque
> chargement de page.

Ah oui, tu as vu le problème. Et donc il y a aussi le cas inverse, où
quelqu'un qui n'est jamais venu sur ton site passe par le même proxy web
que quelqu'un qui y est déjà venu. Idem dans le cas d'un réseau familial
avec NAT.

> Je ne vois pas, comment détecter si c'est le premier chargement ou le
> deuxième, sans ce fichier caractéristique.

Commence donc par définir ce que tu veux dire par « premier » ou
« deuxième » chargement (cf. mes trois cas de figure plus haut).

Généralement, cette notion se gère par un cookie, et dans ce cas le
« deuxième chargement » signifie : je suis déjà venu avec le même
navigateur, lequel accepte les cookies pour ce site.

> J'aurais besoin, que vous me disiez, si mon site fonctionne bien,
> même dans ces conditions ( ce qui est peu probable ), et si celà ne
> fonctionne pas, quel est son comportement.

Je ne peux pas le tester en ce moment. Je suis derrière un proxy (avec
donc la même adresse IP que tous mes collègues) et ce proxy refuse ton
site pour la raison qu'il est dans la catégorie « jeux de hasard ».

> Mon site, si Javascript est activé, détecte aussi si les cookies sont
> acceptés,

Oh, donc tu as aussi pensé aux cookies.

> et sinon, affiche une fenêtre popup en Javascript, suggérant
> d'accepter les cookies.

Attention : mes navigateurs ont JavaScript activé mais ils refusent les
popups. Cela dit, le terme que tu utilises est peut-être impropre, je ne
peux pas le savoir (certaines pages simulent une popup qui n'en est pas
une).

Le mieux à faire, ÀMHA, c'est de mettre en page d'accueil un texte
indiquant tous les prérequis, ce texte pouvant être caché si tu peux
vérifier qu'ils sont tous remplis.

> Pour l'instant, ces deux fonctionnalités ( Javascript et les cookies
> ), ne sont pas strictement nécessaires au fonctionnement de mon site.
>
> Cependant, dans l'optique de mettre en place un module d'inscription
> et d'authentification des visiteurs, pour des fonctionnalités pour
> l'instant gratuites ( envoi automatique quotidien de mes pronostics de
> quinté ), il y aura nécessité pour que les visiteurs soient authentifiés
> que Javascript soit activé,et les cookies permis.

Je ne suis pas un spécialiste, mais je crois que seuls les cookies de
session (temporaires, effacés quand on quitte le navigateur) sont
nécessaires. Et encore, peut-être même pas. Je pense que ni JavaScript
ni les cookies persistents ne sont indispensables.


Cordialement,
--
Olivier Miakinen

Jean Francois Ortolo

unread,
Jun 21, 2012, 1:30:58 PM6/21/12
to

Bonjour Monsieur

Je répond à chacune de vos question ci-dessous.


Pour quelle raison as-tu besoin de distinguer le premier chargement du
> second ?

Parce que... le premier chargement, par définition, se fait
normalement, en mode habituel par le clilent navigateur, et n'a pas
besoin que Javascript soit activé.

Si l deuxième chargement a lieu, c'est donc que Javascript est activé
sur le navigateur, et dans ce cas-là, il me suffit de savoir, si c'est
le premeir ou le deuxième chargement, pour savoir si ( 1er chargement et
condition remplie ), il faut déclencher le second chargement, ou bien (
2ème chargement de la même page, ou bien condition remplie ( que ce soit
le premier ou le second chargement ) ), à ce moment-là, il ne faut
surtout pas déclencher de nouveau chargement, sinon il y aurait, des
pages chargées plusieurs fois.

La seule chose que j'ai besoin de savoir, quand une page est chargée,
et si c'est le premier chargement de la page ( normal ), ou le deuxième
( par Javascript ).

Par ailleurs, j'alimente une variable $_SESSION['js'] , qui est mise
à jour avec le contenu de la fonction php time() ( donc en secondes ),
lorsqu'il y eu une second chargement.

Lorsqu'une nouvelle page est chargée, je vérifie au premier
chargement, que cette variable de session est affectée, et contient une
valeur au moins égale ou supérieure à : ( time() - 30 ). Dans ce cas, il
n'y a pas besoin de second chargement par Javascript, et je réactualise
de nouveau cette variable de session, avec le fonction time() .

Donc... Le fait de charger une fois ou deux fois la page, ne dépend
que de si la variable de session, peut exister ou non.

Par ailleurs... Lors du premier chargement, cette variable de session
peut ne pas exister du tout, ou ne pas dater de moins de 30 secondes.

Mais... Lors du deuxième chargement ( que je dois détecter donc... ),
cette variable de session doit exister et être à jour, sinon celà
indique que les sessions ne fonctionnent pas, donc que le navigateur,
soit a changé d'adresse ip ( je crois que les sessions dépendent de
l'adresse ip cliente, mais si c'est faux, merci de me le dire ;) ),
soit n'a pas mémorisé la session, donc n'accepte pas les cookies.

Dans ces deux cas, le script php lancé par Javascript, s'aperçoit
que, comme c'est le deuxième chargement, c'est que les cookies ne sont
pas acceptés. Ainsi, il rend une valeur spécifique au script Javascript
qui l'a lancé, et celui-ci déclenche une fenêtre modale avec une
instruction Javascript alert() toute simple, sur laquelle le message
s'affiche, suggérant au visiteur, d'accepter les cookies.

Si l'adresse ip du navigateur client, changeait, est-ce que, s'il
acceptait les cookies, cette variable de session $_SESSION['js'] ,
resterait bien mémorisé, et lisible par le script php lancé en mode
Javascript ?

Ce n'est qu'une partie du problème.

Examinons le cas, où une adresse ip modifiée, permettrait quand même
de mémoriser les variables de session, si les cookies étaient permis par
le navigateur client.

Dans ce car, si Javascript n'était pas activé, le script lancé en
Javascript, ne serait pas lancé, et la variable $_SESSION['js'] ne
serait jamais alimentée ( ou une autre variable de session ). Mais si
Javascript était activé, était activé, ce serait la même chose.

Ainsi, je ne pourrais pas distinguer si Javascript est activé ou si
les cookies sont refusés.

Egalement, je ne pourrais pas me servir d'une autre variable de
session, pour savoir si c'est le premier ou le second chargement,
puisque tout se passerait, du point de vue de cette autre variable de
session, comme si c'était toujours le premier chargement... ;(

Si je faisais celà, ce serait pour le coup, qu'il y aurait des
chargements répétitifs sans limite de la même page ( par Javascript s'il
est activé, et que les cookies sont refusés ).

Et dans ce cas... Même chose. Je n'aurai aucun moyen ( autre que ce
fichier caractéristique de l'adresse ip cliente ), de compter, par
exemple, le nombre consécutif de chargements, ou quoi que ce soit qui
nécessite de savoir que c'est le même navigateur qui recharge les pages.

Quant au fichier caractéristique de l'adresse ip...

Entre le premier et le deuxème chargement, il s'écoule très très peu
de temps, seulement quelques fractions de seconde.

De deux chose l'une : Soit l'adresse ip a changé entre les deux
chargements, soit elle n'a pas changé.

Si elle n'a pas changé, çà marche sans problème.

Si elle a changé, le fichier caractéristique de l'adresse ip,
n'existe pas au deuxième chargement, et l'adresse ip vient de changer il
y a très peu de fractions de seconde.

A ce moment-là, le deuxième chargement,e st interprété comme si
c'était un premier chargement, donc il y a un autre chargement.

Dans ce dernier cas, il est pratiquement impossible, que l'adresse ip
change de nouveau avant ce nouveau chargement, à moins que les adresses
ip ne changent excessivement rapidement, ce qui, vous en conviendrez,
est très peu probable.

Tout au plus, je pourrais avoir dans mon répertoire de ces fichiers
caractéristiques, un certain nombre de fichiers qui resteront, à moins
qu'un autre navigateur d'adresse ip identique se présente, ce qui rendra
possible l'effacement de ce fichier ( et sa recréation ).

J'oubliais de vous dire, que dans le script appelé par Javascript, le
fait que la variable de session $_SESSION['js'] soit trop ancienne (
datant de plus de 30 secondes ), se traduit par un effacement de ce
fichier caractéristique s'il existe.

Ensuite, si ce fichier n'existe pas, il est recréé, et le script rend
une valeur, indiquant au script appelant, qu'il doit recharger la page,
en Javascript.



Quelques cas de figure :
> 1) J'ai déjà une fenêtre ouverte sur ton site depuis mon SeaMonkey, et
> j'ouvre une deuxième fenêtre par Ctrl+N. Est-ce un premier chargement
> ou un second ?

Le deuxième chargement dans la première fenêtre est strictement immédiat.

Il n'y a aucune possibilité humainement parlant, d'aller plus vite
que le script Javascript déclenchant aussi le deuxième chargement sur
votre première fenêtre.

Après, sur la deuxième fenêtre, c'est la même adresse ip, et ( je
crois ), la même variable de session $_SESSION['js'] dans les deux cas,
donc il n'y aura qu'un seul chargement, si vous visitez cette page ( ou
n'importe quelle page du site ) dans la deuxième fenêtre, moins de 30
secondes après avoir visité la première page dans la première fenêtre.

Là, tout dépend de savoir si c'est la même session. Théoriquement
c'est la même, puisque c'est le même navigateur, et la même adresse ip
cliente.

Si ce n'est pas la même session, il y aura de toute façon, lors du
premier chargement d'une page ( quelle que soit la page ), deux
chargements à chaque fois.



> 2) J'ai là encore une première fenêtre ouverte depuis mon SeaMonkey, et
> j'en ouvre une autre depuis Firefox, Opera ou Internet Explorer. Même
> question.


C'est un autre navigateur, donc une autre session, donc il y a deux
chargements, lors de la première page chargée, avec chacun de ces
navigateurs.

Et, quel que soit le navigateur, si vous attendez plus de 30 secondes
avant de changer de page ( en cliquant sur un lien , par exemple ;) ),
la nouvelle page sera chargée aussi deux fois.

Le fait de naviguer avec un navigateur dans mon site avec moins de 30
secondes d'attente sur chaque page, fait que quelle que soit la page
suivante, elle n'est chargée qu'une seule fois. ;)


> 3) Enfin, j'ai une première fenêtre ouverte, je quitte mon navigateur et
> je le relance. Je reviens sur ton site. Même question. La réponse
> change-t-elle selon que j'aille directement sur la page que je venais
> de quitter ou que je repasse par la page d'accueil ?
>

Normalement, un navigateur qui a été arrêté, perds le cookie de
session, ou plutôt, celui-ci n'est plus valide après avoir redémarré le
navigateur, et accédé à mon site une nouvelle fois.

Donc, la variable de sessions $_SESSION['js'] n'a pas été mémorisé,
du point de vue du serveur elle n'existe pas, et donc il y a deux
chargements de la page visitée.

Quand ces deux chargements ont eu lieu ( donc Javascript activé ),
quelle que soit la page suivante, la même ou une autre, n'importe
laquelle, le seul critère est le temps d'attente entre deux visites de page.

Un délai > 30 secondes => deux chargements de la nouvelle page.

Un délai <= 30 secondes => un seul chargement de la nouvelle page,
quelle qu'elle soit.


> Je ne suis pas un spécialiste, mais je crois que seuls les cookies de
> session (temporaires, effacés quand on quitte le navigateur) sont
> nécessaires. Et encore, peut-être même pas. Je pense que ni JavaScript
> ni les cookies persistents ne sont indispensables.
>

Ok ;)

C'est sûr, je n'ai pas besoin de cookies persistents.

La plupart du temps, tous les cookies sont effacés quand le
navigateur s'arrête.

D'autre part, je n'ai aucun besoin de mémoriser des habitudes de mes
visiteurs. Cà, c'est la cerise sur le gâteau... ;)


>
> Le mieux à faire, ÀMHA, c'est de mettre en page d'accueil un texte
> indiquant tous les prérequis, ce texte pouvant être caché si tu peux
> vérifier qu'ils sont tous remplis.
>

Pour le Javascript, c'est ce que je fais.

Pour les cookies, je pense que je n'ai pas encore vu, comment
alimenter une variable à partir d'un script Javascript, je vais me
renseigner à ce sujet.

Dans ce cas, je pourrais, plutôt que d'afficher une bête fenêtre
modale Javscript, afficher en php pratiquement le même message que pour
Javascript, dans un rectangle discret, beaucoup plus discret et facile
d'utilisation qu'une fenêtre modale.

En fait, cette fenêtre modale me pose un gros problème d'ergonomie,
car elle nécessite que le visiteur clique sur le bouton"Ok" de la
fenêtre, pour la faire disparaître... Horrible et les visiteurs vont
fuir... ;(

Vous me donnez, une très très bonne idée, et je suis plus que motivé,
pour trouver comment alimenter une variable php, à partir d'une variable
Javascript.

Je pense que c'est une nécessité absolue pour mon site.

Monsieur, je vous suis très très reconnaissant pour vos conseils, qui
me permettront très certainement, d'améliorer beaucoup mon site, de
façon à le rendre plus convivial pour ses visiteurs. ;)

Merci beaucoup de vos conseils.

Avec gratitude.

Olivier Miakinen

unread,
Jun 22, 2012, 6:33:24 AM6/22/12
to
Bonjour,

[Aparté :
J'ai l'habitude de tutoyer sur tous les groupes, alors que tu as
l'habitude de vouvoyer tout le monde. Si la dissymétrie ne te gêne
pas, continuons comme ça. Sinon, je veux bien faire un effort et
revenir au « vous » (je le fais pour une personne qui me l'a demandé
expressément) mais il m'arrive d'oublier.
]

Le 21/06/2012 19:30, Jean Francois Ortolo a écrit :
>
> Pour quelle raison as-tu besoin de distinguer le premier chargement du
> > second ?
>
> Parce que... le premier chargement, par définition, se fait
> normalement, en mode habituel par le clilent navigateur, et n'a pas
> besoin que Javascript soit activé.
>
> Si l deuxième chargement a lieu, c'est donc que Javascript est activé
> sur le navigateur, et dans ce cas-là, il me suffit de savoir, si c'est
> le premeir ou le deuxième chargement, pour savoir si ( 1er chargement et
> condition remplie ), il faut déclencher le second chargement, ou bien (
> 2ème chargement de la même page, ou bien condition remplie ( que ce soit
> le premier ou le second chargement ) ),

Si la question est juste de différencier la requête utilisateur de celle
faite par JavaScript, alors c'est très simple : il suffit de passer un
paramètre différent quand c'est JavaScript qui fait la requête.

Par exemple, l'utilisateur appelle :
http://www.example.com/ma/page/qui/est/belle

Et JavaScript :
http://www.example.com/ma/page/qui/est/belle?idjavascript=untruc

Tu peux même t'assurer de la correspondance entre les deux requêtes si
« untruc » est une très longue chaîne aléatoire générée par le serveur
et mise dans le code JavaScript lors de la réponse à la 1re requête.

Cela dit, il y a peut-être encore plus simple, mais en tout cas tu
n'as rien besoin de bidouiller avec l'adresse IP.

> à ce moment-là, il ne faut
> surtout pas déclencher de nouveau chargement, sinon il y aurait, des
> pages chargées plusieurs fois.

Soit dit en passant, la première chose à faire serait de t'arranger pour
qu'il ne soit jamais grave qu'une page soit chargée plusieurs fois.
Si je me rappelle bien, c'est John Gallet sur fr.comp.lang.php ou sur
fr.comp.applications.sgbd qui, pour commencer, critiquait très fort
l'utilisation de l'auto-incrément dans les bases de données suite à
une requête web (mais comme je n'y connais pas grand chose je peux me
tromper).

> La seule chose que j'ai besoin de savoir, quand une page est chargée,
> [est] si c'est le premier chargement de la page ( normal ), ou le deuxième
> ( par Javascript ).

En principe, tu ne devrais pas avoir besoin de le savoir. Tu que tu
dois savoir, c'est s'il s'agit d'une requête faite sans paramètres
ou bien s'il y a des paramètres à prendre en compte.

> [explications qui me passent un peu au dessus de la tête]

Je laisse répondre les spécialistes des sessions, ce qui n'est pas
mon cas.

> [...]
>
> Ainsi, je ne pourrais pas distinguer si Javascript est activé ou si
> les cookies sont refusés.

Je serais bien étonné que ces deux choses ne soient pas déjà traitées
dans la littérature.

http://www.google.fr/search?q=comment+tester+si+JavaScript+est+actif
http://www.google.fr/search?q=comment+tester+si+les+cookies+sont+actifs

> Egalement, je ne pourrais pas me servir d'une autre variable de
> session, pour savoir si c'est le premier ou le second chargement,
> puisque tout se passerait, du point de vue de cette autre variable de
> session, comme si c'était toujours le premier chargement... ;(
>
> Si je faisais celà, ce serait pour le coup, qu'il y aurait des
> chargements répétitifs sans limite de la même page ( par Javascript s'il
> est activé, et que les cookies sont refusés ).
>
> Et dans ce cas... Même chose. Je n'aurai aucun moyen ( autre que ce
> fichier caractéristique de l'adresse ip cliente ), de compter, par
> exemple, le nombre consécutif de chargements, ou quoi que ce soit qui
> nécessite de savoir que c'est le même navigateur qui recharge les pages.

Euh...
1er appel : http://www.example.com/ma/page/qui/est/belle
2nd appel : http://www.example.com/ma/page/qui/est/belle?count=2
3e appel : http://www.example.com/ma/page/qui/est/belle?count=3
...

Avec dans le code PHP (code approximatif, tests de cohérence non mis) :
$count = isset($_REQUEST["count"]) ? $_REQUEST["count"] : 1;
$count++;
echo "<a href='$url?count=$count'>";

> Quant au fichier caractéristique de l'adresse ip...
>
> Entre le premier et le deuxème chargement, il s'écoule très très peu
> de temps, seulement quelques fractions de seconde.

Ça, tu ne peux pas le savoir. Il suffit d'un changement de route entre
les deux, par exemple, ou tout simplement du passage par un lien très
lent.

> De deux chose l'une : Soit l'adresse ip a changé entre les deux
> chargements, soit elle n'a pas changé.
>
> Si elle n'a pas changé, çà marche sans problème.
>
> Si elle a changé, le fichier caractéristique de l'adresse ip,
> n'existe pas au deuxième chargement, et l'adresse ip vient de changer il
> y a très peu de fractions de seconde.
>
> A ce moment-là, le deuxième chargement,e st interprété comme si
> c'était un premier chargement, donc il y a un autre chargement.
>
> Dans ce dernier cas, il est pratiquement impossible, que l'adresse ip
> change de nouveau avant ce nouveau chargement, à moins que les adresses
> ip ne changent excessivement rapidement, ce qui, vous en conviendrez,
> est très peu probable.

Supposons qu'un tel évènement n'ait qu'une chance sur un million de
se produire. Supposons maintenant que tu aies cent clients par jour,
et que ceux-ci fassent en moyenne cent requêtes par jour. Au bout de
cent jours, tu auras eu un million de requêtes. L'évènement qui n'a
qu'une chance sur un million de se produire devient du coup beaucoup
moins improbable, n'est-ce pas ?

De toute manière, ta méthode me semble excessivement compliquée alors
qu'il te suffit, dans chaque réponse à une requête, de mettre ce qu'il
faut pour que la requête suivante soit parfaitement déterminée comme
étant une « suite ». Pas besoin de contrôle d'adresse IP, pas besoin
de gestion du temps, juste un id de session et un numéro d'ordre.

> [...]
>
> Quelques cas de figure :
> > 1) J'ai déjà une fenêtre ouverte sur ton site depuis mon SeaMonkey, et
> > j'ouvre une deuxième fenêtre par Ctrl+N. Est-ce un premier chargement
> > ou un second ?
>
> Le deuxième chargement dans la première fenêtre est strictement immédiat.
>
> Il n'y a aucune possibilité humainement parlant, d'aller plus vite
> que le script Javascript déclenchant aussi le deuxième chargement sur
> votre première fenêtre.

Ah ? Et si j'ouvre deux fenêtres en même temps vers le site ?

> Si ce n'est pas la même session, il y aura de toute façon, lors du
> premier chargement d'une page ( quelle que soit la page ), deux
> chargements à chaque fois.

Soit dit en passant, je n'ai toujours pas compris pourquoi il fallait
deux chargements. Le serveur ne peut pas envoyer toutes les infos
requises en une seule fois ? Ou alors c'est pour tester que JavaScript
fonctionne ? Mais dans ce dernier cas il doit y avoir un moyen plus
simple.

> > 2) J'ai là encore une première fenêtre ouverte depuis mon SeaMonkey, et
> > j'en ouvre une autre depuis Firefox, Opera ou Internet Explorer. Même
> > question.
>
> C'est un autre navigateur, donc une autre session, donc il y a deux
> chargements, lors de la première page chargée, avec chacun de ces
> navigateurs.
>
> Et, quel que soit le navigateur, si vous attendez plus de 30 secondes
> avant de changer de page ( en cliquant sur un lien , par exemple ;) ),
> la nouvelle page sera chargée aussi deux fois.
>
> Le fait de naviguer avec un navigateur dans mon site avec moins de 30
> secondes d'attente sur chaque page, fait que quelle que soit la page
> suivante, elle n'est chargée qu'une seule fois. ;)

Et le résultat est le même, selon qu'une *nouvelle* page soit chargée
une fois (avant 30 secondes) ou deux fois ? C'est pour punir les
visiteurs lents ou ayant une connection peu rapide ?

> Un délai > 30 secondes => deux chargements de la nouvelle page.
>
> Un délai <= 30 secondes => un seul chargement de la nouvelle page,
> quelle qu'elle soit.

Ça me semble vraiment trop bizarre, je n'arrive pas à comprendre la
raison profonde qui peut te pousser à faire cela.

> Vous me donnez, une très très bonne idée, et je suis plus que motivé,
> pour trouver comment alimenter une variable php, à partir d'une variable
> Javascript.

JavaScript :
if (il n'y a pas encore de '?')
url = url + '?var=valeur';
else
url = url + '&var=valeur';
... puis appel de l'url qui contient du code PHP.

PHP :
$_REQUEST['var']


Cordialement,
--
Olivier Miakinen

Tonton Th

unread,
Jun 22, 2012, 11:05:52 PM6/22/12
to
On 06/19/2012 12:15 PM, Jean Francois Ortolo wrote:

> caractéristique de l'adresse ip du visiteur,

Et si le visiteur change d'IP ?

--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/


Jean Francois Ortolo

unread,
Jun 24, 2012, 5:11:02 AM6/24/12
to
Le 22/06/2012 12:33, Olivier Miakinen a écrit :
> Bonjour,
>
> [Aparté :
> J'ai l'habitude de tutoyer sur tous les groupes, alors que tu as
> l'habitude de vouvoyer tout le monde. Si la dissymétrie ne te gêne
> pas, continuons comme ça. Sinon, je veux bien faire un effort et
> revenir au « vous » (je le fais pour une personne qui me l'a demandé
> expressément) mais il m'arrive d'oublier.
> ]
>


Bonjour Monsieur

Je vous prie de bien vouloir m'excuser de vous vouvoyer. ;)

C'est un signe d'amitié.

Voilà, j'ai constaté, que de mon point de vue de programmeur PHP et
HTML, j'étais dans l'impossibilité de savoir, avec mon algorithme, si le
fait que la variable de session $_SESSION['js'] n'était pas alimenté
correctement, est du au fait, soit que Javascript n'est pas activé, soit
les Cookies refusés, soit les deux.

Cependant, je pourrais faire ce distinguo ( du moins ne pas avoir à
faire de fenêtre modale gênante pour les utilisateurs, et simplement les
avertir du fait exact, en changeant en PHP l'intitulé du message affiché
sur l'écarn ( mais pas de fenêtre modale par alert() en Javascript ) ),
si et seulement si, je savais comemnt affeectr une variable PHP, à
partir d'une variable Javascript.

Vous m'avez dit, pour celà : Lancer en Javascript un script prenant
en paramètre GET cette variable, et récupérer le résultat rendu par ce
script, en PHP.

Cependant, je n'arrive pas à savoir, comment ce serait possible, sur
le plan de la programmation, de faire celà. Particulièrement le type de
séquencement à appliquer, et comment disposer les instructions.

Je peux effectivement, en PHP utiliser les instructions de type
curl_*() pour gérer le lancement et la réception des données d'un script
PHP.

Il me semble, que quand la portion de code qui lance un script, est
aussi celui qui en reçoit les résultats.

Je suis dans le noir.

Jje ne vois pas du tout, quelle est la logique de séquencement de ces
opérations ( en javascript, puis en PHP ).

Je vous serais très reconnaissant, si vous pouviez me donner plus de
précisions si le procédé à mettre en oeuvre pour celà.

Merci beaucoup pour vos réponses.

Olivier Miakinen

unread,
Jun 24, 2012, 7:50:20 PM6/24/12
to
Le 24/06/2012 11:11, Jean Francois Ortolo a écrit :
>
> Je vous prie de bien vouloir m'excuser de vous vouvoyer. ;)

Tu es tout excusé, si de ton côté tu me pardonnes de te tutoyer !

> Voilà, j'ai constaté, que de mon point de vue de programmeur PHP et
> HTML, j'étais dans l'impossibilité de savoir, avec mon algorithme, si le
> fait que la variable de session $_SESSION['js'] n'était pas alimenté
> correctement, est du au fait, soit que Javascript n'est pas activé, soit
> les Cookies refusés, soit les deux.

D'accord. Alors vu que les cookies n'ont pas besoin de JavaScript, je
suppose que tu peux utiliser la fonction setcookie() et la variable
$_COOKIE pour tester ça.

Voir par exemple <http://php.net/manual/fr/function.setcookie.php>,
et aussi les liens listés au bas de cette page (« Voir aussi »).

Et donc, si le cookie mis par setcookie() est correct mais que celui
mis par JavaScript ne l'est pas, tu sauras que JavaScript est désactivé
alors que les cookies ne sont pas refusés.

> [...]
>
> Vous m'avez dit, pour celà : Lancer en Javascript un script prenant
> en paramètre GET cette variable, et récupérer le résultat rendu par ce
> script, en PHP.

Non, c'est *toi* qui as dit que la seconde requête était faite par
JavaScript. J'ai juste dit que dans ce cas il suffit de demander à
JavaScript de faire une requête différente de celle faite par le
visiteur.

> Cependant, je n'arrive pas à savoir, comment ce serait possible, sur
> le plan de la programmation, de faire celà. Particulièrement le type de
> séquencement à appliquer, et comment disposer les instructions.
>
> Je peux effectivement, en PHP utiliser les instructions de type
> curl_*() pour gérer le lancement et la réception des données d'un script
> PHP.

Ouh là ! Tu as plusieurs serveurs PHP qui s'appellent les uns les
autres ? Si oui, tu pourrais être amené à faire du Curl pour qu'un
script PHP sur un serveur lance à distance un programme PHP sur un
autre serveur. Sinon, un simple appel de fonction est plus que
suffisant dans l'immense majorité des cas.

> Il me semble, que quand la portion de code qui lance un script, est
> aussi celui qui en reçoit les résultats.
>
> Je suis dans le noir.
>
> Jje ne vois pas du tout, quelle est la logique de séquencement de ces
> opérations ( en javascript, puis en PHP ).

Comme je ne connais pas la profondeur de tes interrogations et d'une
éventuelle confusion, je t'invite d'abord à lire ceci :
<http://faqfclphp.free.fr/#rub2.3>.

Tu dois comprendre que les programmes PHP et JavaScript ne tournent
*jamais* en même temps sur la même tâche.

En premier lieu, il y a une requête HTTP qui est faite du client au
serveur. Lors de la transmission de cette requête, ni JavaScript ni
PHP ne tournent.

Quand le serveur reçoit la requête, il construit la réponse. Cette
construction de réponse peut se faire en PHP, mais pendant ce temps
là JavaScript ne fait rien. Même si le PHP écrit du code JavaScript,
ce code n'est pas exécuté du tout.

Ensuite, la réponse est envoyée du serveur au client. À ce moment là,
PHP a complètement fini de travailler, le programme s'est arrêté et
toute sa mémoire a été libérée. Pourtant JavaScript n'est pas encore
lancé.

À présent, le HTML est arrivé sur le client. Si ce code HTML contient
du JavaScript, le client peut l'exécuter. Éventuellement, ce code
JavaScript peut construire une *nouvelle* requête HTTP, qui lancera
un *nouveau* script PHP lors d'un *nouveau* lancement du programme
PHP sur le serveur.


Cordialement,
--
Olivier Miakinen

Jean Francois Ortolo

unread,
Jun 25, 2012, 4:34:17 AM6/25/12
to

Bonjour Monsieur ;)

Grâce à vous et votre lien, j'ai la réponse à ma question.

Celà signifie en fait, faire un refresh de la page, donc relancer
cete même page en Javascript ( c'est facile ), avec en paramètre post (
de préférence post, pour éviter d'interférer avec les autres paramètres
de la page) la valeur Javascript souhaitée.

En effet, je fais de l'urlrewriting pour les pages de mon site
www.pronostics-courses.fr ;)

Celà fait, qu'il n'y aura pas de problème, pour relancer la page en
mode post, puisque les autres paramètres, sont intégrés à l'url de la page.

En fait, faire un refresh de la page, est précisément ce que je fais
déjà, en rechargeant la page si Javascript est activé. ;)

Donc, à cet endroit du code Javascript ( relancement de cette page ),
il me suffit d'intégrer en paramètre post, la valeur qui indiquera à ce
même script php, si les cookies sont acceptés ou refusés.

Ouf, merci beaucoup, vous avez trouvé la réponse à mes questions. ;)

D'autre part, j'ai changé d'avis pour ce qui est de la mémorisation
des données, nécessaires au bon fonctionnement de cet algorithme. ;)


Pour la suite, le traitement php suivant ( l'algorithme ), est fait
par un script session_js.php, lancé par Javascript en mode synchrone par
la page chargée par le visiteur.

Au lieu d'écrire des fichiers me servant de repère si c'est le
premier chargement de la page ou le deuxième ( par Javascript ),je vais
alimenter une table MySQL du type :

CONNEXION(MAINTENANT FLOAT KEY NOT NULL DEFAULT 0,
CODE INTEGER NOT NULL KEY DEFAULT 0,
IP_ADDRESS VARCHAR(100) KEY NOT NULL DEFAULT '';


Le critère pour savoir si le visiteur a déjà chargé une page (
n'importe laquelle ), est le suivant :

A chaque requête HTTP d'un visiteur, on a son adresse ip, dont on ne
garde que la partie significative, qui ne tient pas compte des éléments
variables d'une adresse ip éventuellement variable.

Merci beaucoup, si vous pouviez m'indiquer, dans un contexte
habituel, soi en ip4, soit en ip6, avec une connexion variable de type :
téléphone mobile, ou bien aol, ou bien FAI sans adresse ip fixe,
etc... comment sélectionner la partie fixe de l'adresse ip ( le
commencement de l'adresse, en tenant compte de combien de points,
suivant que l'adresse est en ip4 ou en ip6 ). ;)


Donc à chaque requête HTTP, on lit la valeur de la variable de
session éventuelle $_SESSION['CODE']

Si elle est alimentée, et existe dans la table CONNEXION, il n'y a
pas de refresh, car session_js.php rend 'OK' à la page appelante.

Dans tous les cas, le script session_js.php alimente une variable
$_SESSION['js'] = time();

Si cette variable n'existe pas dans la page, c'est que Javascript est
désactivé et/ou les Cookies refusés. Mais si Javascript est désactivé,
il est impossible de savoir lequel des deux, ou les deux.

Dans ce cas, le message affiché sur la page appelante, indique
simplement qu'il faut activer Javascript, et accepter les Cookies. ( A
l'impossible nul n'est tenu ;) )


Si $_SESSION['CODE'] n'existe pas dans CONNEXION, ou n'est pas
alimentée, on regarde dans la table CONNEXION, si la partie
significative de l'adresse ip cliente, existe déjà dans la table, et
date de moins de $delai_max microsecondes.

$delai_max est le nombre maximal de microsecondes, que la page met
avant de se rafraîchir, dans le cas où il y a eu un refresh.

Si cette donnée de l'adresse ip cliente existe dans ces conditions,
c'est que c'est le deuxième chargement ( i y a déjà eu un refresh ).

Là, il y a deux cas :

Si $_SESSION['CODE'] est alimentée ( valeur non existante dans
CONNEXION ), les cookies sont acceptés, et Javascript activé, donc on ne
fait rien de plus ( session_js.php rend 'OK', et le fait qu'il n'y a pas
de paramètre POST $NO_COOK à la page appelante, lui indique que les
cookies sont acceptés.

Si $_SESSION['CODE'] n'existe pas, c'est que les cookies sont
interdits, donc session_js.php rend 'NO_COOK' au script appelant, qui
recharge la page en Javascript ( deuxième refresh ), en passant à la
page, en mode POST, un paramètre $NO_COOK= true;

Si ce paramètre de la page existe et a déjà cette valeur, on ne fait
pas le traitement ci-dessus, donc plus de refresh, Javascript activé, et
les Cookies sont refusés.

2b-
Si cette donnée de l'adresse ip cliente n'existe pas dans ces
conditions, ( c'est le script session_js.php qui fait tout le traitement
MySQL ), c'est qu'il n'y a pas eu de refresh de la page.

Donc, session_js.php , génère un code aléatoire CODE, avec la
fonction crypt($_SERVER['REMOTE_ADDRESS']), ou une autre fonction plus
efficace, après avoir fait un srand(time()); , pour réinitialiser
d'uneamnière élaatoire, le séquencement de la fonction cryp().

Il met cette variable CODE en session : $_SESSION['CODE'] = $CODE;

Puis il enregistre dans la table CONNEXION, ce CODE, la partie
significative de l'adresse ip dans IP_ADDRESS, puis la valeur de
microtime() dans MAINTENANT.

Comme le visiteur n'est jamais passé sur la page, session_js.php rend
'BAD' à page apelant, qui fait un refresh.

En plus de çà, à la fin du script session_js.php , celui-ci efface
systématiquement de la table CONNEXION, les enregistrements plus vieux
que le temps maximal, qu'un visiteur peut passer sur une seule page,
avant de changer de page, ou de la recharger manuellement.

Le fait qu'il puisse y avoir deux refresh, ne peut se produire, que
si Javscript est activé, et les Cookies refusés.

Je ne garde pas les adresses ip entières, seulement la partie fixe

Le critère pour savoir si Javascript n'est pas activé, est si
$_SESSION['js'] n'existe pas, et il n'y a pas de paramètre $NO_COOK.

Dans ce cas,pas de refresh.

Si $NO_COOK existe, c'est que Javascript est activé, et les Cookies
refusés.

Dans ce cas, deux refresh dans tous les cas. ( trois chargements de
la même page ).

Si $NO_COOK n'existe pas, et $_SESSION['js'] existe, Javascript est
activé et les Cookies acceptés.

Dans ce cas, un refresh, seulement si $_SESSION['js'] date de plus du
temps maximal théorique que met un visiteur, avant de recharger une page
manuellement.

Normalement, il n'y a pas de refresh, après un seul refresh initial.

Si les Cookies sont refusés, et Javascript activé, il y a
obligatoirement deux refresh dans tous les cas, mais hélas, je ne crois
pas que je puisse faire autrement, pour distinguer les cas :

Les Cookies refusés, et Javascript activé, ou Javascript désactivé.


Que pensez -vous de cet algorithme ? ;)

Merci beaucoup de votre réponse.

Jean Francois Ortolo

unread,
Jun 25, 2012, 5:38:48 AM6/25/12
to


Rebonjour Monsieur

J'ai pensé à quelque chose, pour savoir si les cookies sont acceptés
ou non.

Il me suffirait simplement, dans la page appelante, d'alimenter une
autre variable de session, et de vérifier si elle est alimentée.

Dans tous les cas si Javascript n'est pas activé, il n'y a pas de
refresh, donc je n'aurais pas le moyen, dans la page appelante, de faire
cette variable de session, puis de vérifier qu'elle existe, s'il n'y a
pas de refreh de la page.

Merci de me le confirmer.

Si c'est possible de savoir immédiatement après avoir alimenté une
variable de session, qu'elle existe, celà me soulagerait, car je saurais
tout de suite si les cookies sont refusés, même si Javascript est désactivé.

Et puis, que ce soit le cas ou non, celà me permettra, de ne plus
avoir au maximum, qu'un seul refresh au lieu de deux, et ceci, dans la
plus mauvaise configuration possible, où le visiteur attendrait plus que
le temps maximal admis, pour recharger une page manuellement.

Mais si c'est possible de savoir ( voir ci-dessus ), alors je pourrai
facilement, savoir indépendamment l'un de l'autre, si Javscript est
activé ou non,et si les Cookies sont acceptés ou non.

Ce serait l'idéal.

Merci beaucoup de votre réponse.

Bien amicalement.

Jean François Ortolo




Olivier Miakinen

unread,
Jun 25, 2012, 6:50:11 AM6/25/12
to
Bonjour,

Le 25/06/2012 10:34, Jean Francois Ortolo a écrit :
>
> Grâce à vous et votre lien, j'ai la réponse à ma question.

Je ne sais pas lequel des deux liens, mais je suis content d'avoir
pu te rendre service.

> [...]
>
> A chaque requête HTTP d'un visiteur, on a son adresse ip, dont on ne
> garde que la partie significative, qui ne tient pas compte des éléments
> variables d'une adresse ip éventuellement variable.

???

Qu'est-ce qu'une adresse ip « éventuellement variable » ? Une adresse
dont le FAI ne garantit pas qu'elle soit fixe ? Et qu'est-ce que cette
« partie significative » ?

> Merci beaucoup, si vous pouviez m'indiquer, dans un contexte
> habituel, soi en ip4, soit en ip6, avec une connexion variable de type :
> téléphone mobile, ou bien aol, ou bien FAI sans adresse ip fixe,
> etc... comment sélectionner la partie fixe de l'adresse ip ( le
> commencement de l'adresse, en tenant compte de combien de points,
> suivant que l'adresse est en ip4 ou en ip6 ). ;)

Non, je ne le peux pas. Ou plutôt si : tu peux considérer que tu as
0 bits fixes, soit 32 bits variables en IPv4 et 128 bits variables
en IPv6.

Quoique... en IPv6, si tu n'as aucun client utilisant une adresse
privée ou un adresse local de lien, tu peux considérer que les
trois premiers bits sont vraiment fixes, c.-à-d. les adresses entre
2000:0:0:0:0:0:0:0 et 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.

Mais encore une fois, je ne vois pas l'intérêt de tenir compte
d'autre chose que des données utiles pour l'échange : url,
paramètres (de type get ou de type post) ou infos de session.
Ce d'autant plus que, comme on l'a déjà signalé, un visiteur
peut avoir plusieurs adresses IP (successivement ou même
simultanément), et plusieurs visiteurs peuvent avoir la même
adresse IP simultanément.

Par exemple, en ce moment, la machine sur laquelle je suis
répond à deux adresses IPv4 et à cinq adresses IPv6, mais
si j'arrivais à joindre ton serveur tu la verrais avec une
troisième adresse IPv4, la même que pour chacun de mes
collègues.

> [...]
>
> Que pensez -vous de cet algorithme ? ;)

Rien, car personnellement je n'ai jamais fait que des pages web
beaucoup plus simples, sans sessions ni cookies. J'espère n'être
pas le seul à suivre cette discussion car d'autres sont certainement
beaucoup plus au fait que moi de ces techniques.

Si au moins j'ai pu te convaincre d'abandonner le stockage d'adresse
ip qui ne peut t'amener que des problèmes, alors j'estimerai vraiment
t'avoir aidé. ;-)

Cordialement,
--
Olivier Miakinen

Olivier Miakinen

unread,
Jun 25, 2012, 6:59:59 AM6/25/12
to
Le 25/06/2012 11:38, Jean Francois Ortolo a écrit :
>
> [...]
>
> Si c'est possible de savoir immédiatement après avoir alimenté une
> variable de session, qu'elle existe, celà me soulagerait, car je saurais
> tout de suite si les cookies sont refusés, même si Javascript est désactivé.

Immédiatement, c'est-à-dire sans attendre la requête suivante ?

Si j'ai bien compris la question, c'est que tu as besoin de relire
ceci : <http://faqfclphp.free.fr/#rub2.3> (ou mes explications
suivant la fois où j'ai donné ce lien).

Mais je suppose qu'en fait j'ai mal compris la question, auquel cas
je te prie de m'excuser.

> Et puis, que ce soit le cas ou non, celà me permettra, de ne plus
> avoir au maximum, qu'un seul refresh au lieu de deux [...]

Un seul refresh au lieu de deux, c'est-à-dire deux requêtes seulement
au lieu de trois ? Si oui, c'est qu'effectivement j'avais mal compris.
Et donc oui, quand tu as alimenté une variable de session ou un cookie,
tu dois pouvoir le vérifier dès la requête suivante.

> Le 25/06/2012 10:34, Jean Francois Ortolo a écrit :
>>
>> [copie intégrale]

Oups ! Tu as oublié d'effacer les citation inutiles...

Jean Francois Ortolo

unread,
Jun 25, 2012, 11:50:13 AM6/25/12
to


Bonjour Monsieur ;)

Je répond à vos questions, ci-dessous.

Merci beaucoup de vos réponses.

Bien amicalement.

Jean François Ortolo


Le 25/06/2012 12:50, Olivier Miakinen a écrit :
> Bonjour,
>
> Qu'est-ce qu'une adresse ip « éventuellement variable » ? Une adresse
> dont le FAI ne garantit pas qu'elle soit fixe ? Et qu'est-ce que cette
> « partie significative » ?
>

Dans ma terminologie, et pour mes besoins actuels de cette
application, une adresse ip variable, est une adresse qui peut varier au
cours de la navigation d'un visiteur sur mon site.

Par exemple, en passant d'une page à une autre page, le temps passé
sur la première page, serait théoriquement, pour une adresse ip
variable, suffisant pour que l'adresse ip cliente présentée à la
deuxième page, puisse être différente que celle présentée à la première
page.

Evidemment,le degré de variation des adresses ip durant l'ensemble de
la navigation su même visiteur sur mon site, déterminerait la façon dont
je pourrais calculer la partie fixe de l'adresse ip, durant toute la
navigation du même visiteur.

Cette navigation continue, suppose que le visiteur a une connexion
internet qui ne s'arrête pas durant la navigation, puisque celle-ci est
supposée continuer, durant la visite du visiteur sur mon site.

Si la connexion internet du visiteur, cessait de fonctionner, ne
serait-ce que momentanément, alors ce ne serait plus la même visite du
visiteur....

Pour une adresse ip variable dans ce contexte ( c'est le cas pour le
FAI AOL ), j'ai cru comprendre, que les adresses ip, pouvaient varier au
cours d'une même connexion internet, mais simplement, soit pour le
dernier nombre de l'adresse ip ( en ip4, après le dernier point de
l'adresse ), soit pour les deux derniers nombres de l'adresse ( en ip4,
après l'avant-dernier point de l'adresse ).

C'est surtout ce type de degré maximal de variation de l'adresse ip
*au cours d'une même connexion internet*, dont j'ai besoin, pour
calculer la partie fixe de l'adresse ip, qui serait simplement l'adresse
ip, privée de sa partie variable.

De toute manière, mon algorithme, suppose que j'efface à chaque
requête http, de la table CONNEXION, les enregistrements plus anciens
que le temps maximal qu'un visiteur peut rester sur une page, sans le
recharger manuellement, ni changer de page.

Donc, il ne m'importe pas, que l'adresse ip puisse varier, plus que
durant cette période maxi, où le visiteur le plus curieux et avide
d'analyser les données de mon site, peut vouloir rester sur la même page.

Par ailleurs, celà non plus n'est pas important, car si le visiteur
dépasse ce délai maximal, la page chargée ensuite, sera seulement
chargée deux fois, avec un refresh, car le visiteur sera simplement
considéré comme un autre visiteur.

Et ceci, seulement si son adresse ip, varie.

>
> Mais encore une fois, je ne vois pas l'intérêt de tenir compte
> d'autre chose que des données utiles pour l'échange : url,
> paramètres (de type get ou de type post) ou infos de session.
> Ce d'autant plus que, comme on l'a déjà signalé, un visiteur
> peut avoir plusieurs adresses IP (successivement ou même
> simultanément), et plusieurs visiteurs peuvent avoir la même
> adresse IP simultanément.
>

C'est bien.

J'identifie que c'est le même visiteur, avec des infos de session.
Très bien.

Et si les cookies sont refusés ? Alors à chaque fois c'est un nouveau
visiteur, donc c'est le premier chargement de la page, donc il y a un
refresh systématique et répétitif sans fin, si les cookies sont refusés ?

J'avoue que ce que je pourrais faire, lors du premier chargement,
serait de faire le refresh ( donc, deuxième chargement de la page en
mode Javascript ), avec le protocole get, et un paramètre qui s'il
existe, me servirait à savoir que c'est le deuxième chargement.

Toutes les urls de mon site sont urlrewritées, et de suffixe .html,
sans paramètre get. Plus exactement, tous les paramètres sont intégrés à
l'url , avant le suffixe .:html , et séparés par des virgules.

Le fichier .htaccess fait la traduction, de telle façon que l'url qui
apparaît dans la barre du navigateur, soit encore l'url rewritée.

Effectivement, je pourrais modifier en php, avant le script
Javascript, l'url de la page, pour lui adjoindre le paramètre
supplémentaire à l'intérieur de l'url, puis sachant que le paramètre
supplémentaire n'était pas présent ( après le premier chargement ),
relancer en Javascript la même page.

Lors du premier chargement, j'alimenterais une variable de session,
dont je vérifierais l'existence après le deuxième chargement.

Ainsi, je n'aurais plus à savoir la provenance ( identifier le
visiteur ) des requêtes HTTP, et je pourrais même me payer le luxe (
comme je fais déjà ), de ne pas faire ce refresh, si ce délai maximal
dont je parle ci-dessus, n'est pas dépassé entre deux pages chargées.

Si Javascript est activé, mais les Cooies refusés, je le saurais
après le premier refresh ( deuxième chargement de la même page ), et à
ce moment-là, je ne pourrais avoir une idée du délai entre deux
chargements manuels de deux pages ( différentes ou identiques ), qu'en
mettant quelque chose identifiant le visiteur... Mais quoi ?

Comment enregistrer dans une table MySQL, des données correspondant à
un visiteur, pour savoir lors du premier chargement d'une page, que ce
même visiteur, a déjà visité une autre page, dans un délai suffisamment
court, pour qu'il ne soit pas nécessaire de faire un refresh de cette
nouvelle page ?

Y a-t-il un autre moyen pour faire celà ( si les Cookies sont refusés
), que de pouvoir identifier le visiteur ?

Au moins savoir, que c'est ce même visiteur inscrit dans cette table
MySQL, depuis la précédente page chargée par ce visiteur ?

C'est sûr, que je ne demande pas à identifier un visiteur entre deux
visites. Je n'en ai pas besoin.

Effectivement, si je ne peux pas identifier le visiteur, là je suis
carrément obligé, de faire un refresh et un seul, sur toutes les pages,
qui seront toutes, chargées deux fois.

Ceci, car je ne peux pas savoir le délai écoulé entre deux
chargements manuels de pages par le même visiteur, à moins de savoir que
c'est le même visiteur que lors du précédent chargement de page.

Je ne pourrais le savoir, que si le visiteur accepte les Cookies... ;(

Si le visiteur n'accepte pas les Cookies, problème insoluble ?

Dans ce cas, un refresh obligatoire à chaque page ?

C'est tout à fait vrai, que ce nouvel algorithme, est bien plus
performant que le mien... ;)

Merci beaucoup, de me dire si ce problème ci-dessus, est insoluble ?

Merci beaucoup de vos réponses.

Paul Gaborit

unread,
Jun 25, 2012, 12:13:50 PM6/25/12
to

À (at) Mon, 25 Jun 2012 12:59:59 +0200,
Olivier Miakinen <om+...@miakinen.net> écrivait (wrote):

> Le 25/06/2012 11:38, Jean Francois Ortolo a écrit :
[...]
>
>> Et puis, que ce soit le cas ou non, celà me permettra, de ne plus
>> avoir au maximum, qu'un seul refresh au lieu de deux [...]
>
> Un seul refresh au lieu de deux, c'est-à-dire deux requêtes seulement
> au lieu de trois ? Si oui, c'est qu'effectivement j'avais mal compris.
> Et donc oui, quand tu as alimenté une variable de session ou un cookie,
> tu dois pouvoir le vérifier dès la requête suivante.

Une méthode assez classique pour poser un cookie et vérifier son
fonctionnement immédiatement sans passer par un refresh consiste à
l'associer à une redirection.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Tonton Th

unread,
Jun 25, 2012, 1:11:08 PM6/25/12
to
On 06/25/2012 05:50 PM, Jean Francois Ortolo wrote:

> Evidemment,le degré de variation des adresses ip durant l'ensemble de
> la navigation su même visiteur sur mon site, déterminerait la façon dont
> je pourrais calculer la partie fixe de l'adresse ip, durant toute la
> navigation du même visiteur.

Il m'arrive de passer dans un endroit où il y a un
répartiteur de charge qui fait que la sortie vers
le Ternet peut se faire par Free, par Orange ou
par une ls. Il n'y a PAS de partie fixe.

Jean Francois Ortolo

unread,
Jun 25, 2012, 5:39:32 PM6/25/12
to
Le 25/06/2012 19:11, Tonton Th a écrit :
> On 06/25/2012 05:50 PM, Jean Francois Ortolo wrote:
>
>> Evidemment,le degré de variation des adresses ip durant l'ensemble de
>> la navigation su même visiteur sur mon site, déterminerait la façon dont
>> je pourrais calculer la partie fixe de l'adresse ip, durant toute la
>> navigation du même visiteur.
>
> Il m'arrive de passer dans un endroit où il y a un
> répartiteur de charge qui fait que la sortie vers
> le Ternet peut se faire par Free, par Orange ou
> par une ls. Il n'y a PAS de partie fixe.
>


Bonsoir Monnsieur

Le cas dont vous parlez, n'est pas courant.

Les visiteurs sur mon site, viennent pour l'immense majorité, en fait
la totalité, de connexions internet à un seul FAI en même temps.

Je chercherai l'information dont j'ai besoin ( partie fixe d'une
adresse ip variable ), sur Google.

Quant au reste du nouvel algorithme que Monsieur Miakinen m'a
suggéré, et qui est effectivement beaucoup plus performant que le mien,
je n'ai besoin pour passer à la programmation, que de savoir comment
traiter le cas où Javascript est activé, et les Cookies refusés.

Comment, dans ce cas-là, savoir si le visiteur qui visite votre page
peu de temps après une première visite sur une page (la même ou une
autre, peu importe ), est bien passé sur le site il y a très peu de temps ?

Ceci, sans les Cookies ?

Comment, sans les Cookies, transformer en gros, le protocole HTTP,
qui ne mémorise pas les accès http, en protocole avec mémoire ?

Je ne demande pas le feu, simplement une mémoire très courte, de
quelques secondes.

30 secondes me suffirait.

Celà me permettrait, de ne pas faire de refresh si le délai depuis le
dernier chargement manuel d'une page sur mon site ( n'importe laquelle
), est inférieur à 30 secondes.

Je n'ai besoin, que d'une mémorisation de 30 secondes, ce n'est pas
la mer à boire ...

Olivier Miakinen

unread,
Jun 25, 2012, 7:40:43 PM6/25/12
to
Le 25/06/2012 23:39, Jean Francois Ortolo répondait à Tonton Th :
>>
>>> Evidemment,le degré de variation des adresses ip durant l'ensemble de
>>> la navigation su même visiteur sur mon site, déterminerait la façon dont
>>> je pourrais calculer la partie fixe de l'adresse ip, durant toute la
>>> navigation du même visiteur.
>>
>> Il m'arrive de passer dans un endroit où il y a un
>> répartiteur de charge qui fait que la sortie vers
>> le Ternet peut se faire par Free, par Orange ou
>> par une ls. Il n'y a PAS de partie fixe.

De même pour moi. Contrairement au boulot où je partage une adresse IP
avec tous mes collègues, chez moi j'ai l'adresse IP 87.231.69.87 par le
câble (Numericable) mais il suffirait que je branche une seconde carte
Ethernet sur la box pour en avoir une autre *en même temps*, c'est-à-
dire que sur 100 requêtes successives je pourrais très bien changer
100 fois d'adresse IP.

> Le cas dont vous parlez, n'est pas courant.

Quand bien même c'était encore peu courant avec IPv4, l'arrivée d'IPv6
fera qu'il deviendra quasiment la norme d'avoir plusieurs adresses
actives simultanément.

> Les visiteurs sur mon site, viennent pour l'immense majorité, en fait
> la totalité, de connexions internet à un seul FAI en même temps.

Quand bien même un utilisateur n'aurait qu'un seul FAI, ça n'empêche
qu'il peut changer d'adresse IP sans changer de FAI :

<cit.>
fr.telecom
France Telecom S.A.

19930901 193.248.0.0/14 ALLOCATED UNSPECIFIED
19930901 193.252.0.0/15 ALLOCATED UNSPECIFIED
19930927 194.2.0.0/16 ALLOCATED UNSPECIFIED
19950111 194.51.0.0/18 ALLOCATED PA
19950711 194.3.0.0/16 ALLOCATED UNSPECIFIED
19951019 194.206.0.0/16 ALLOCATED PA
19951019 194.51.128.0/17 ALLOCATED PA
19951019 194.51.64.0/18 ALLOCATED PA
19960304 194.250.0.0/16 ALLOCATED PA
19960730 195.6.0.0/16 ALLOCATED PA
19961101 195.25.0.0/16 ALLOCATED PA
19970307 195.101.0.0/16 ALLOCATED PA
19970501 62.160.0.0/16 ALLOCATED PA
19980416 212.234.0.0/16 ALLOCATED PA
19980729 62.161.0.0/16 ALLOCATED PA
19990802 213.56.0.0/16 ALLOCATED PA
20001222 217.108.0.0/15 ALLOCATED PA
20010115 217.128.0.0/16 ALLOCATED PA
20010406 217.167.0.0/16 ALLOCATED PA
20010503 80.8.0.0/13 ALLOCATED PA
20020325 81.48.0.0/13 ALLOCATED PA
20020326 81.80.0.0/16 ALLOCATED PA
20030213 81.248.0.0/13 ALLOCATED PA
20031021 82.120.0.0/13 ALLOCATED PA
20031212 83.112.0.0/14 ALLOCATED PA
20031212 83.192.0.0/12 ALLOCATED PA
20050302 86.192.0.0/10 ALLOCATED PA
20060302 90.0.0.0/9 ALLOCATED PA
20070712 92.128.0.0/10 ALLOCATED PA
20091007 109.208.0.0/12 ALLOCATED PA
20100712 2.0.0.0/12 ALLOCATED PA
20000623 2001:0688::/35
20020717 2001:0688:2000::/35
20020717 2001:0688:4000::/34
20020717 2001:0688:8000::/33
</cit.>

> Je chercherai l'information dont j'ai besoin ( partie fixe d'une
> adresse ip variable ), sur Google.

Les quelques lignes citées ci-dessus, je les ai copiées depuis
<ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt>
(lien trouvé via Google).


Cordialement,
--
Olivier Miakinen

Jean Francois Ortolo

unread,
Jun 26, 2012, 2:31:56 AM6/26/12
to


Bonjour Monsieur

Je vous prie de bien vouloir m'excuser.

J'avais mal compris ce que vous disiez, quand vous mentionniez les
urls comme un moyen de suivre un visiteur.

J'ai trouvé, qu'il me suffit de générer un code strictement aléatoire
et non répétitif, si la variable $CODE est vide ou n'existe pas au
départ, puis dans ce cas, d'alimenter une table MySQL, avec ce CODE et
sur un autre champ, la valeur de la fonction microtime()

Cette variable $CODE étant rendue globale dans les deux scripts que
j'ai programmés pour cette gestion de Javascript et des Cookies ( le
premier prog_allopass.php aussi pour la gestion des paiments Allopass),
et le second no_repeat.php uniquement pour le Javascript et les Cookies.

La variable $CODE, étant globale, est accessible de tous les scripts
contenant ces deux scripts, et donc je peux tout simplement, la
transmettre systématiquement, à chaque urls du site.

En fait, celà revient à faire des sessions dans les urls, et çà a
l'inconvénient pour le référencement auprès de Google, de multiplier les
urls différentes, ce qui devrait occasionner, des "duplicate content" du
point de vue de Google, qui aura probablement tendance à voir celà d'un
mauvais oeil. ;(

Effectivement, dans ces conditions, pas besoin de l'adresse ip des
visiteurs.

Une seule question : Google n'aime pas du tout, que l'on fasse un
traitement différent sur son site, suivant que c'est un bot de Google
qui visite le site ( le reverse des adresses ip des bots de Google
contiennent le mot "ggogle" ;) ), ou quelqu'un d'autre...

Je vais poser la question de la possibilité de faire celà (
désactiver ce processus, ne pas faire de refresh, et garder cette
variable $CODE à la chaîne vide, si c'est un bot de Google , ou
éventuellement un autre moteur de recherche.

Ce procédé, pourrait avoir un impact négatif sur le bon référencement
de mon site, qui est actuellement, très bien référencé par Google.

Cependant, je pense personnellement, que celà n'en vaut pas la
chandelle, de risquer le référencement de mon site, simplement pour
distinguer les deux cas : Javascript désactivé, et puis soit les Cookies
permis, soit refusés.

Je vais donc certainement, appliquer l'algorithme utilisant cette
table MySQL CONNEXION, que j'ai décrit dans un précédent message sur ce
thread, et si le cas ci-dessus advient, le message mentionnera
systématiquement les deux : Javascript à activer, et les Cookies à accepter.

Simplement, au lieu d'alimenter une autre variable de session à partir
de session_js.php , je l'alimenterai à partir du script appelant, et si
Javascript est activé, le refresh simplement, adjoindra à l'url de
relancement en get de la page, la variable $COOK positionnée à 0

Il n'y aura donc, qu'un seul refresh au lieu de deux.

Je m'arrangerai, pour que les urls relancés, soient urlrewritées, et
comme la variable $COOK éventuelle dans les urls du site, n'a qu'une
seule valeur possible ( son absence indique que les Cookies sont
acceptés ), il y a très peu de possibilité de duplicate content.

Et... Si Javascript n'est pas activé, $_SESSION['js'] n'existe pas,
c'est testé dans les scripts prog_allopass.php et no_repeat.php après le
script Javascript, donc sans distinguo, le message mentionne le fait,
qu'il faut activer Javacsript,et permettre les Cookies.

Et puis, tant qu'à faire, ce n'est même pas nécessaire d'utiliser
cette variable $COOK, qui ne sert qu'à savoir si les Cookies sont permis
ou non ( si Javascript est activé ), donc je vais m'en passer, et ne pas
distinguer du tout, les cas où Javascript est désactivé, et/ou les
Cookies refusés.

Ainsi, plus du tout de duplicate content,et Google aussi sera content. ;)

Comme vous le savez, le duplicate content, désigne le fait, d'avoir
plusieurs urls, pour le même contenu de page html.

En tout cas, en plus de çà, je vais probablement, faire des stats sur
les nombres de visites et visiteurs uniques, mais pour çà,
effectivement, je n'ai pas besoin de Javascript... ;)

Comme pour l'instant je loggue les urls de provenance ( visiteurs
uniques ), dans ces fichiers, j'ai pu me rendre copte de visu, que le
nombre de visiteurs uniques quotidiens, est très supérieur à ce que
m'indique Google Analytics... ;)

Merci beaucoup pour votre aide.

Très amicalement. ;)

Jean François Ortolo


Olivier Miakinen

unread,
Jun 26, 2012, 5:57:57 AM6/26/12
to
Bonjour,

Le 26/06/2012 08:31, Jean Francois Ortolo a écrit :
>
> J'avais mal compris ce que vous disiez, quand vous mentionniez les
> urls comme un moyen de suivre un visiteur.
>
> [...]
>
> En fait, celà revient à faire des sessions dans les urls, et çà a
> l'inconvénient pour le référencement auprès de Google, de multiplier les
> urls différentes, ce qui devrait occasionner, des "duplicate content" du
> point de vue de Google, qui aura probablement tendance à voir celà d'un
> mauvais oeil. ;(

Même si je crois savoir que Google ne considère pas comme « duplicate
content » le cas où deux url ne diffèrent que par les paramètres (après
le « ? »), l'url n'est que la possibilité la plus simple.

Une autre consiste à créer un formulaire avec champs hidden, dont la
soumission est lancée par JavaScript. Ainsi, non seulement tu as ton
refresh, tu vérifies au passage que JavaScript fonctionne (si le
bouton est invisible et n'est accessible que par JS), et il n'y a
aucun paramètre passé dans l'url (c'est dans les champs hidden).

> Effectivement, dans ces conditions, pas besoin de l'adresse ip des
> visiteurs.

Ouf !

Cordialement,
--
Olivier Miakinen

Olivier Masson

unread,
Jun 26, 2012, 6:16:23 AM6/26/12
to
Le 25/06/2012 23:39, Jean Francois Ortolo a écrit :
> Le 25/06/2012 19:11, Tonton Th a écrit :
>> On 06/25/2012 05:50 PM, Jean Francois Ortolo wrote:
>>
>>> Evidemment,le degré de variation des adresses ip durant l'ensemble de
>>> la navigation su même visiteur sur mon site, déterminerait la façon dont
>>> je pourrais calculer la partie fixe de l'adresse ip, durant toute la
>>> navigation du même visiteur.
>>
>> Il m'arrive de passer dans un endroit où il y a un
>> répartiteur de charge qui fait que la sortie vers
>> le Ternet peut se faire par Free, par Orange ou
>> par une ls. Il n'y a PAS de partie fixe.
>>
>
>
> Bonsoir Monnsieur
>
> Le cas dont vous parlez, n'est pas courant.
>

C'est de plus en plus courant, du simple fait que la connexion internet
est capitale pour bon nombre de professionnels désormais.
Je vais installer un routeur dual-wan avec load balancing dans 15j. Il y
a la possibilité d'orienter l'algo de répartition pour que l'ip reste
constante durant toute la session, mais ce n'est pas le comportement par
défaut je crois.

Jean Francois Ortolo

unread,
Jun 26, 2012, 7:21:43 AM6/26/12
to
Le 26/06/2012 11:57, Olivier Miakinen a écrit :
> Bonjour,
>>
>> En fait, celà revient à faire des sessions dans les urls, et çà a
>> l'inconvénient pour le référencement auprès de Google, de multiplier les
>> urls différentes, ce qui devrait occasionner, des "duplicate content" du
>> point de vue de Google, qui aura probablement tendance à voir celà d'un
>> mauvais oeil. ;(
>
> Même si je crois savoir que Google ne considère pas comme « duplicate
> content » le cas où deux url ne diffèrent que par les paramètres (après
> le « ? »), l'url n'est que la possibilité la plus simple.
>
> Une autre consiste à créer un formulaire avec champs hidden, dont la
> soumission est lancée par JavaScript. Ainsi, non seulement tu as ton
> refresh, tu vérifies au passage que JavaScript fonctionne (si le
> bouton est invisible et n'est accessible que par JS), et il n'y a
> aucun paramètre passé dans l'url (c'est dans les champs hidden).
>


Rebonjour Monsieur

Le problème, c'est que toutes mes urls sont urlrewritées... ;(

Donc le problème du duplicate content, se pose.

Cependant, je pense aussi, que le cas indiqué par Monsieur Masson
ci-dessous, ne se produit qu'excessivement rarement, dans le contexte de
mon site,qui est un site de Turf, qui donne des statistiques et des
pronostics sur les courses de chevaux.

J'ai revu le cours sur le web dynamique du site www.saphirtech.com de
Monsieur John Gallet, qui aborde ce problème de suivre un visiteur
durant sa navigation.

Cependant, effectivement, il n'indique comme moyen de transmettre
l'id de session, que dans les urls , ou bien en utilisant les sessions
natives de php.

Je pense pour ma part, que mon procédé, d'identifier durant au
maximum 30 secondes, un visiteur, par la partie fixe de son adresse ip,
devrait fonctionner suffisamment correctement.

Je vais donc simplement, changer mon algorithme actuellement en place
sur mon site, en modifiant la mémorisation des données d'identification,
qui seront dans uen table MySQL, au lieu de fichiers de logs.

Au pire, le seul problème qui puisse survenir, est si la partie fixe
de l'adresse ip, change entre le chargement d'une page, et son refresh.

Dans ce cas, il y aura un autre refresh, et ainsi de suite jusqu'à ce
que cette donnée de l'adresse ip soit la même que la précédente. ;)

Merci beaucoup de votre aide.

Paul Gaborit

unread,
Jun 26, 2012, 4:27:27 PM6/26/12
to

� (at) Tue, 26 Jun 2012 11:57:57 +0200,
Olivier Miakinen <om+...@miakinen.net> �crivait (wrote):

> Une autre consiste � cr�er un formulaire avec champs hidden, dont la
> soumission est lanc�e par JavaScript. Ainsi, non seulement tu as ton
> refresh, tu v�rifies au passage que JavaScript fonctionne (si le
> bouton est invisible et n'est accessible que par JS), et il n'y a
> aucun param�tre pass� dans l'url (c'est dans les champs hidden).

Les param�tres d'une requ�te (m�me s'ils proviennent de champs cach�s)
apparaissent en clair dans l'URL si la requ�te est de type GET. Pour
qu'ils soient non pas dans l'URL mais dans le document de la requ�te, il
faut utiliser la m�thode POST.

Paul Gaborit

unread,
Jun 26, 2012, 4:48:55 PM6/26/12
to

� (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo
<ortolo.jeanfr...@free.fr.invalid> �crivait (wrote):

> J'ai revu le cours sur le web dynamique du site www.saphirtech.com de
> Monsieur John Gallet, qui aborde ce probl�me de suivre un visiteur
> durant sa navigation.
>
> Cependant, effectivement, il n'indique comme moyen de transmettre l'id
> de session, que dans les urls , ou bien en utilisant les sessions
> natives de php.

Question (dont la r�ponse devrait pouvoir vous servir): comment PHP
(avec ses sessions natives) connait-il l'id de session si celui-ci
n'appara�t pas dans l'URL ? (Au passage, que ce soit en PHP, en Perl, en
Python, les diff�rentes techniques permettant de g�rer une session Web
sont toujours les m�mes.)

Si vous ne connaissez pas la r�ponse � la question ci-dessus, faites de
tests avec les sessions natives de PHP et analysez les �changes entre le
serveur et le navigateur via Firebug par exemple. Vous en apprendrez
beaucoup plus comme cela qu'en essayant d'imaginer votre propre
m�thode...

> Je pense pour ma part, que mon proc�d�, d'identifier durant au maximum
> 30 secondes, un visiteur, par la partie fixe de son adresse ip, devrait
> fonctionner suffisamment correctement.

Je pense r�ellement que vous avez tort ! D'autant que vous vous
focalisez sur ce probl�me compl�tement annexe de "partie fixe" d'une
adresse IP alors que les deux vrais probl�mes insolubles sont :

1 - plusieurs utilisateurs peuvent utiliser la m�me adresse IP.
2 - un utilisateur peu changer compl�tement d'IP � chaque requ�te.

Une fois admis ces deux points, vous ne pouvez qu'en d�duire qu'une
identification (fiable) par la seule adresse IP est vou�e � l'�chec.
Les m�thodes qui marchent (par URL, par donn�es POST ou par cookie
�ventuellement combin� � du HTTPS pour s�curiser l'ensemble) ne reposent
pas sur l'adresse IP.

PS: tout cela n'a plus rien � voir avec javascript et la d�tection de
sa disponibilit� sur le poste client. Ce sont bien des questions
compl�tement s�par�es.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>

Jean Francois Ortolo

unread,
Jun 26, 2012, 9:05:57 PM6/26/12
to
Le 26/06/2012 22:48, Paul Gaborit a �crit :
>
> � (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo
> <ortolo.jeanfr...@free.fr.invalid> �crivait (wrote):
>
>> Je pense pour ma part, que mon proc�d�, d'identifier durant au maximum
>> 30 secondes, un visiteur, par la partie fixe de son adresse ip, devrait
>> fonctionner suffisamment correctement.
>
> Je pense r�ellement que vous avez tort ! D'autant que vous vous
> focalisez sur ce probl�me compl�tement annexe de "partie fixe" d'une
> adresse IP alors que les deux vrais probl�mes insolubles sont :
>
> 1 - plusieurs utilisateurs peuvent utiliser la m�me adresse IP.
> 2 - un utilisateur peu changer compl�tement d'IP � chaque requ�te.
>


Bonsoir Monsieur

J'ai mis au point sur mon site, le proc�d� que je mentionnais.

Apr�s une premier essai avec les trois premiers nombrss dss adreses
ip4, j'ai voulu tester en prenant les adresses ip enti�res, si
r�ellement il y a un risque, que les adresses ip changent rapidement.

Je met dans ma table MySQL, avec le champ drapeau � 0, la valeur de
la fonction NOW() de MySQL, et l'adresse ip enti�re.

Ceci, pour les don�nes tr�s temproaires, qui ne durent pas plis de 30
secondes.

Pour les donn�es servant � des statistiques de trafic ( nombres de
visiteurs quotidiens par exemple ), je garde ces m�mes donn�es, mais
avec le champ drapeau � 1.

Celles-ci, je les garde un mois et demi.

Comme j'ai les adresses ip enti�res, que je les garde longtemps, ,et
que je peux les trier par ordre chronologique, il me sera facile de
voir, si effectiveemt il ya d es addreses ip ,ressemblantes entre elles,
qui se suivent rapidement.

Je pourrai ainsi, savoir quel est le degr� de variation r�elle, de
ces adreses ip.

Merci beaucoup de votre aide.

Bien amicalement.

Jean Fran�ois Ortolo




Paul Gaborit

unread,
Jun 27, 2012, 3:55:27 AM6/27/12
to

� (at) Wed, 27 Jun 2012 03:05:57 +0200,
Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid> �crivait (wrote):

> J'ai mis au point sur mon site, le proc�d� que je mentionnais.
>
[...]
>
> Je pourrai ainsi, savoir quel est le degr� de variation r�elle, de ces
> adreses ip.

Pourquoi demandez dans un forum et lire des tutoriaux ou des cours si
vous ne suivez pas les conseils que vous y trouvez ?

PS: votre syst�me ne d�tectera jamais l'usage d'une seule adresse IP par
plusieurs utilisateurs.

Jean Francois Ortolo

unread,
Jun 27, 2012, 5:05:17 AM6/27/12
to
Le 27/06/2012 09:55, Paul Gaborit a écrit :
>
> Pourquoi demandez dans un forum et lire des tutoriaux ou des cours si
> vous ne suivez pas les conseils que vous y trouvez ?
>
> PS: votre système ne détectera jamais l'usage d'une seule adresse IP par
> plusieurs utilisateurs.
>



Bonjour Monsieur

Je n'ai rien à dire à çà, si ce n'est que je pense plus que je ne
dis... ;)

Jean Francois Ortolo

unread,
Jun 27, 2012, 7:18:51 AM6/27/12
to
Le 27/06/2012 09:55, Paul Gaborit a écrit :
>
> À (at) Wed, 27 Jun 2012 03:05:57 +0200,
> Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid> écrivait (wrote):
>
>> J'ai mis au point sur mon site, le procédé que je mentionnais.
>>
> [...]
>>
>> Je pourrai ainsi, savoir quel est le degré de variation réelle, de ces
>> adreses ip.
>
> Pourquoi demandez dans un forum et lire des tutoriaux ou des cours si
> vous ne suivez pas les conseils que vous y trouvez ?
>
> PS: votre système ne détectera jamais l'usage d'une seule adresse IP par
> plusieurs utilisateurs.
>


Bonjour Monsieur

Est-ce possible, que plusieurs visiteurs avec la même adresse ip ,
visitent mon site strictement en même temps, à 30 secondes près ?

C'est le seul problème à résoudre.

Dans le cas contraire, pas de problème.

J'ai mis en place, l'enregistrement dans la table MySQL CONNEXION, de
toutes les adresses ip datant de moins de 35 jours.

Du moins, j'ai d'abord pris les adresses ip entières ( c'est de
l'ip4, apparemment personne de mes visiteurs n'est en ip6 ), mais j'ai
constaté qu'il y avait des adresses très similaires qui se suivaient de
manière rapprochée en ordre chronologique.

Donc, j'ai pu voir de visu, que ces adresses, ne diffèrent que par
leur dernier nombre.

Ces adresses, correspondent donc avec certitude, à des adresses ip
variables.

Le degré de variation minimum étant fixé, j'ai modifié mon package,
pour éliminer ce dernier nombre des adresses ip, donc je ne garde que
les trois premiers nombres ( pour l'ip4 ), et pour l'instant en théorie
( je ne peux pas vérifier pour le moment, il n'y a pas d'adresses ip6 ),
j'élimine les deux derniers nombres des adresses ip6.

Prochainement, je vérifierai si ce degré de variation des adresses
ip, est fiable, donc suffisant pour isoler les visiteurs uniques pour
mon algorithme, sachant que ces variations, ne peuvent être que
limitées, puisque ce sont des adresses ip présentées à au plus, quelques
secondes d'intervalle.

Quant aux enregistrements sur 35 jours, j'aurai la possibilité, de
trier sur les adresses ip, donc de voir si sur un intervalle de 35
jours, le degré de variation est plus important ou non.

Moralité : Rien ne vaut l'expérience.

Bien à vous.

Amicalement.

Jean François Ortolo


Jean Francois Ortolo

unread,
Jun 27, 2012, 7:33:41 AM6/27/12
to

Rebonjour

J'ajoute, après n'avoir pris que les trois premiers nombres des
adresses ip4 :

Il faudrait que j'enregistre dans CONNEXION, également les adresses
ip entières ( avec un champ drapeau à 3 au ieu de 2, qui correspond à la
période de 35 jours ), pour me rendre compte s'il y a des adresses ip
différentes, qui sont considérées comme identiques, par les
enregistrements avec drapeau =1 ( période = 30 secodes, adresses ip
fitrées ).

Ainsi, je pourrais savoir, si dans l'espace de 30 secondes, il se
peut que des adresses ip filtrées identiques, correspondent à des
adresses ip réelles entièrement différentes, c'est-à-dire non variables.

Théoriquement, celà pourrait être le cas, si des abonnés d'un FAI
identique, visitent mon site en même temps.

Mais.. L'intervalle maxi n'est que de 30 secondes, alors...

Je vais rajouter tout de suite, ces enregistrements, dans le seul
script à modifier.

Paul Gaborit

unread,
Jun 27, 2012, 7:52:10 AM6/27/12
to

À (at) Wed, 27 Jun 2012 11:05:17 +0200,
Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid> écrivait (wrote):

> Je n'ai rien à dire à çà, si ce n'est que je pense plus que je ne
> dis... ;)

Tant mieux. ;-)

> Bien amicalement.

De même.

Paul Gaborit

unread,
Jun 27, 2012, 11:49:36 AM6/27/12
to

À (at) Wed, 27 Jun 2012 13:18:51 +0200, Jean Francois Ortolo
<ortolo.jeanfr...@free.fr.invalid> écrivait (wrote):

> Est-ce possible, que plusieurs visiteurs avec la même adresse ip ,
> visitent mon site strictement en même temps, à 30 secondes près ?

Oui. Selon la nature du site, c'est même potentiellement très
courant. Exemple: un formateur qui indique à tous ses participants
d'utiliser votre site. Ils sont tous derrière un proxy (une seule
adresse ip de votre point de vue) et viennent tous visiter votre site au
même moment. On peut avoir un cas similaire avec les différentes
machines dans une maison (elles sont toutes derrière la même box).

> J'ai mis en place, l'enregistrement dans la table MySQL CONNEXION, de
> toutes les adresses ip datant de moins de 35 jours.
>
> Du moins, j'ai d'abord pris les adresses ip entières ( c'est de l'ip4,
> apparemment personne de mes visiteurs n'est en ip6 ), mais j'ai constaté
> qu'il y avait des adresses très similaires qui se suivaient de manière
> rapprochée en ordre chronologique.

Pourquoi ne pas exploiter les traces de votre serveurs web ? En plus de
l'adresse IP, vous pouvez facilement utiliser le champs 'referer'. C'est
plus fiable pour essayer de suivre un visiteur.

Pourquoi ne pas utiliser les cookies pour suivre à coup sûr vos
visiteurs uniques ?

[...]
> Moralité : Rien ne vaut l'expérience.

Mais sans la compréhension de ce qui n'est pas directement perceptible,
c'est un échec garanti (cf. la parabole des aveugles et de l'éléphant).

Jean Francois Ortolo

unread,
Jun 27, 2012, 10:01:55 PM6/27/12
to


Rebonsoir ;)

Finalement, j'ai entièrement modifié la logique de mémorisation du
fait de si c'est le premier ou le deuxième chargement.

J'ai changé les index des trois champs de ma table MySQL CONNEXION (
en local pour l'instant ), en trois index séparés multiples.

Celà me permet, d'enregistrer plusieurs visites séparées, venant
théoriquement de la même adresse ip ( qu'elle soit variable ou non ).


Voici l'algorithme :

Il y a deux valeurs pour le champ drapeau : 0 et 1.

Le 0 déclenche un refresh ( le script Javascript est lancé, par une
condition php ), le 1 ne le déclenche pas.

Tout le traitement, se fait en amont du script Javscript éventuel,
donc celui-ci ne s'exécute, que si le champ drapeau est à 0.

Si le champ drapeau est à 1, c'est que le refresh éventuel, a déjà eu
lieu, donc il n'y a plus de refresh, donc le script Javascript
n'apparaît pas dans le source html.

Voici la logique de modifications en amont, des valeurs du champ
drapeau, pour l'enregistrement adéquat :

Au début du scrpt, le script regarde si une adresse ip identique (
l'adresse ip est filtrée, je ne prend que les trois premiers nombres,
pour une adresse ip4 ), n'existe pas déjà dans la table CONNEXION,
depuis 10 secondes au plus.

Si oui, le premier chargement de la page a eu lieu.

Dans ce cas, le script fait un un update de l'enreg trouvé, en
mettant le champ maintenant à now() ( fonction MySQL donnant le
timestamp courant ), et en mettant le champ drapeau à 1, ce qui empêche
un nouveau refresh. ( Le refresh a déjà eu lieu, puisqu'il a rechargé la
page même qui est en train de s'exécuter ).

Si non, le script cherche le maximum du champ maintenant dans la
table CONNEXION, qui date de moins de 20 minutes ( temps théorique
maximal d'une visite ). Dans ce cas, la visite continue, et même chose :

Le script fait un update de l'enreg trouvé, en mettant maintenant à
now() , et le champ drapeau à 0, puisque celà fait plus de 10 secondes
que la précédente requête http de la même adresse ip, a été faite.

Donc, c'est le premier chargement. Le script Javascript va se
déclencher, et il y aura un refresh.

Si le script ne trouve pas le maximum du champ maintenant existant
dans CONNEXION datant de moins de 20 minutes, ce n'est pas la même
visite, même si cette même adresse ip, peut avoir visité le site il y a
plus que 20 minutes.

Dans ce cas, le script insère dans CONNEXION, les coordonnées de la
nouvelle visite : now() pour maintenant, l'adresse ip filtrée pour le
champ ip_address, et le champ drapeau =0, puisque c'est le premier
chargement. Il va donc y avoir un refresh.

Le scrtpt Javacript, avant de déclencher un refresh, lance le script
session_js.php , qui se contente d'alimenter la variable de session :
$_SESSION['js'] = time();

A la fin du script appelant, il vérifie si $_SESSION['js'] est
alimentée et date de moins de 30 secondes, sinon, il en déduit que
Javascript est désactivé ou ( ce qui revient au même pour mon message,
je ne distingue pas les deux ) que le Coookies sont refusés.

Le seul problème dans tout çà, est de fixer le temps maxi d'une visite.

En fait, c'est le temps maximal qu'un visiteur peut passer sur une
page, sans changer de page.

Je pense, que je pourrais sans problème, raccourcir beaucoup cette
durée de 20 minutes.

En fait, j'ai confondu dans mon compte Google Analytics, avec la
durée maximale d'une visite, mais ce qui m'intéresse, c'est la durée
maximale de consultation d'une page... ;)

Je pense, qu'avec une durée théorique , de mettons, 3 minutes,
j'aurais plus de chance, de ne pas avoir deux adresses ip filtrées
identiques, provenant de visiteurs différents.

Raccourcir cette durée, n'a pas d'importance, car celà revient à faire
comme si la visite est une nouvelle visite, donc à simplement refaire un
refresh.

Je pense même, que la valeur actuelle sur mon site, de 30 secodnes,
est suffisante.

J'ai programmé cet algorithme en local sur mon ordinateur, mais il y
a encore une toute petite erreur, qui vient du traitement des urls (
noms et emplacements des pages, et paramètres ).

Bien à vous.

Amicalement.

Jean François Ortolo


PS Cet algorithme est incomplet ou imprécis, car il est bientôt 4
heures du matin, et ma passion de l'informatique, me joue des tours... ;)

Aussi, je suis preneur de toutes suggestions.constructives... ;)

Très amicalement.




Olivier Miakinen

unread,
Jun 28, 2012, 5:08:16 AM6/28/12
to
Le 26/06/2012 22:27, Paul Gaborit complétait ma réponse :
>
>> Une autre consiste à créer un formulaire avec champs hidden, dont la
>> soumission est lancée par JavaScript. Ainsi, non seulement tu as ton
>> refresh, tu vérifies au passage que JavaScript fonctionne (si le
>> bouton est invisible et n'est accessible que par JS), et il n'y a
>> aucun paramètre passé dans l'url (c'est dans les champs hidden).
>
> Les paramètres d'une requête (même s'ils proviennent de champs cachés)
> apparaissent en clair dans l'URL si la requête est de type GET. Pour
> qu'ils soient non pas dans l'URL mais dans le document de la requête, il
> faut utiliser la méthode POST.

Oui, merci de le préciser. Donc un formulaire avec méthode POST.

Olivier Miakinen

unread,
Jun 28, 2012, 5:28:58 AM6/28/12
to
Bonjour,

Le 27/06/2012 13:18, Jean Francois Ortolo a écrit :
>
> Est-ce possible, que plusieurs visiteurs avec la même adresse ip ,
> visitent mon site strictement en même temps, à 30 secondes près ?

Oui, bien sûr. Comme je l'ai déjà dit plus d'une fois, de mon lieu
de travail j'utilise la même adresse IP de sortie que mes quelques
centaines de collègues, puisque nous passons tous par le même proxy
http. Il doit être assez fréquent que deux personnes parmi ces
plusieurs centaines accèdent au même site en même temps, à trente
secondes près.

Par ailleurs, ma femme et moi utilisons aussi la même adresse IP
quand nous sommes à la maison, celle du routeur de notre FAI qui
utilise NAT (Network Address Translation).

> C'est le seul problème à résoudre.

Mais enfin, pourquoi est-ce un problème ? Pourquoi diable as-tu
besoin de ces deux requêtes à moins de trente secondes d'intervalle,
contrôlées par adresse IP ? Que font deux requêtes que ne ferait
pas une seule ?

> Le degré de variation minimum étant fixé, j'ai modifié mon package,
> pour éliminer ce dernier nombre des adresses ip, donc je ne garde que
> les trois premiers nombres ( pour l'ip4 ), et pour l'instant en théorie
> ( je ne peux pas vérifier pour le moment, il n'y a pas d'adresses ip6 ),
> j'élimine les deux derniers nombres des adresses ip6.

Si c'est pour faire ça, autant garder la totalité de l'adresse... ou
rien ! Quelqu'un qui change d'adresse peut changer pour une dont tous
les octets sont différents, tandis que deux personnes différentes
peuvent avoir la même adresse au bit près.

À la limite, je me demande s'il ne serait pas possible qu'une requête
se fasse en IPv4 et la suivante en IPv6, ou le contraire.

> Prochainement, je vérifierai si ce degré de variation des adresses
> ip, est fiable, donc suffisant pour isoler les visiteurs uniques [...]

Je crois t'avoir dit plusieurs fois que ce n'était pas le cas. Si
tu veux, un soir je peux t'envoyer une série de quelques requêtes,
alternativement d'un Linux et d'un Windows (mon PC et celui de ma
femme), en l'espace de quelques secondes.

> Moralité : Rien ne vaut l'expérience.

Moralité : l'expérience est une lanterne que l'on porte dans le dos
et qui n'éclaire jamais que le chemin parcouru¹. Corollaire : on a beau
essayé de te communiquer notre propre expérience, puisque tu as décidé
de ne pas en tenir compte rien ne te fera changer d'avis.

--
Olivier Miakinen

(¹) Confucius, je crois.

Olivier Miakinen

unread,
Jun 28, 2012, 5:34:55 AM6/28/12
to
Le 28/06/2012 04:01, Jean Francois Ortolo a écrit :
>
> PS [...] il est bientôt 4
> heures du matin, et ma passion de l'informatique, me joue des tours... ;)

Je comprends bien mieux pourquoi tu ne veux pas renoncer à ton algo de
reconnaissance de l'adresse IP : c'est ta passion de l'informatique
qui te fait t'y accrocher, car tu l'aimes cet algo. Étant moi-même
informaticien et passionné, j'ai aussi connu ce sentiment qui dépasse
parfois la raison...

> Aussi, je suis preneur de toutes suggestions.constructives... ;)

... et donc, notre suggestion de tout virer, tu ne *peux* pas la
juger constructive, puisqu'elle détruit cette passion. Désolé, je
te souhaite de revenir à la raison, mais cela pourra prendre des
mois ou des années avant que tu y viennes.

Cordialement,
--
Olivier Miakinen

Tonton Th

unread,
Jun 28, 2012, 6:13:57 AM6/28/12
to
On 06/28/2012 04:01 AM, Jean Francois Ortolo wrote:

> ( l'adresse ip est filtrée, je ne prend que les trois premiers nombres,
> pour une adresse ip4 )

Tout le monde n'est pas sur un /24 ;)

Olivier Miakinen

unread,
Jun 28, 2012, 6:29:47 AM6/28/12
to
Le 28/06/2012 11:28, j'écrivais :
>
> on a beau essayé

Ça aussi, c'est beau et pas mal essayé ! ;-)

[suivi en privé]

Jean Francois Ortolo

unread,
Jun 28, 2012, 10:26:38 AM6/28/12
to


Bonjour Monsieur

J'ai programmé l'algorithme correct, et mis en place sur mon site.

Au lieu de 20 minutes pour une consultation d'une page, je l'ai fixé
à 5 minutes max.

D'après le contenu actuel de la table CONNEXION, il ne semble pas y
avoir de problèmes causés par des adresses ip variables.

En effet, j'enregistre aussi dans une colonne supplémentaire
complete_ip_address de la table CONNEXION, les adresses ip non filtrées.

S'il y avait des problèmes causés par des changements d'adresses ip,
je le saurais, car il y aurait des adresses ressemblantes qui se
suivent, en ordre chronologique.

Or , ce n'est pas le cas.

Vous pouvez vérifier sur mon site, s'il y a des problèmes éventuels.

Olivier Miakinen

unread,
Jun 28, 2012, 10:57:38 AM6/28/12
to
Bonjour,

Le 28/06/2012 16:26, Jean Francois Ortolo a écrit :
>
> J'ai programmé l'algorithme correct, et mis en place sur mon site.

Tu fais bien comme tu veux...

> S'il y avait des problèmes causés par des changements d'adresses ip,
> je le saurais, car il y aurait des adresses ressemblantes qui se
> suivent, en ordre chronologique.

Non. Si une machine utilise deux adresses IP, soit successivement
soit simultanément, ces deux adresses n'ont aucune raison d'être
« ressemblantes ».

> Vous pouvez vérifier sur mon site, s'il y a des problèmes éventuels.

Vu que je ne sais pas ce qui est censé mal se passer si tu ne fais
qu'une requête au lieu de deux, je ne vois pas ce que je pourrais
vérifier. Je me suis connecté, pour voir, de chez moi (d'ici je ne
peux pas) et je n'ai rien vu de particulier.

À l'occasion, tu voudras bien nous expliquer (en langage courant,
pas en terme de PHP et SQL) ce qu'est censé apporter ce système de
doubles requêtes ?

Cordialement,
--
Olivier Miakinen

Jean Francois Ortolo

unread,
Jun 28, 2012, 12:08:55 PM6/28/12
to
Le 28/06/2012 16:57, Olivier Miakinen a écrit :
> Bonjour,
>
> À l'occasion, tu voudras bien nous expliquer (en langage courant,
> pas en terme de PHP et SQL) ce qu'est censé apporter ce système de
> doubles requêtes ?
>
> Cordialement,
>



Bonjour Monsieur

L'intérêt, est de détecter si le navigateur client, a Javascript
activé ou non, e/ou les Cookies acceptés ou non.

Si l'un de deux, ou les deux, sont interdits, alors un message
s'affiche en haut de l'écran de pratiquement toutes les pages de mon
site, indiquant qu'il est souhaitable d'activer Javascript,et de
permettre les Cookies.

Je ne distingue pas, les deux possibilités de Javascript et des
Cookies, et le message est le même dans tous les cas où ce message
apparaît.

Pour l'instant, je n'ai pas besoin de celà, mais à terme, si je rend
mon site payant, le système de paiement Allopass ( que j'ai déjà
programmé sur mon site, mais n'est pas actif ), nécessite que Javascript
soit activé, et les Cookies acceptés.

Dans mes deux scripts de configuration, si la constante PAYANT est
égale à 0, le système de paiement est désactivé.

Si elle vaut 1, le système de paiement est actif, et n'apparaît que
dans les pages de statistiques et pronostics, du lendemain ou du soir,
et ceci, seulement pour les Courses à événement ( Quinté, Quarté
Régional, Classic Tiercé, Multi ou 2 sur 4 ).

Le reste est laissé gratuit, comme produit d'appel pour mes clients
futurs.

Le système de paiement, inclut des abonnements par Carte Bleue, ou
bien des appels téléphoniques surtaxés, ou par SMS, pour obtenir le
code/mot de passe, qui sera reçu par mon site avec les autres
coordonnées du client, si le paiement est validé par Allopass.

Ce système de paiement, inclut une inscription déclenchée
automatiquement en Javascript au moment de l'abonnement, pour que les
clients puissent être identifiés, et joint par leur login et leurs
adresses email.

Un client abonné ( paiement CB ), doit s'authentifier avec son login
et son code/mot de passe, pour accéder aux ressources protégées.

Le futur client qui s'abonne, doit d'abord donner son pseudo ( unique
dans la database ), et son adresse email, dont la syntaxe est vérifiée,
puis la fenêtre d'abonnement d'Allopass, s'affiche automatiquement, et
le client, soit paye, soit s'abstient.

Si le paiement est valide, le client revient automatiquement à la
page d'origine, est il est authentifié automatiquement.

Ceci, également dans le cas d'un paiement par téléphone.

Comme vous voyez, cette interface de paiement, du moins le
séquencement des opérations, est aussi convivial que possible, pour que
le client ne soit pas désorienté. ;)

Je n'ai pas encore entièrement vérifié ave certitude, les deux
scripts qui seront appelés sur mon site par le site Allopass, après un
paiement valide, soit par téléphone, soit par carte Bancaire, soit
autres moyens de paiement possibles.

Dans l'état actuel, la constante PAYANT est à 0, donc le système de
paiement n'apparaît pas, et mon site est gratuit. ;)

J'ai testé l'interface du système de paiement que j'ai programmée,
sur mon ordinateur en local, en faisant en sorte, que les fonctions
Javascript mises en oeuvre par ce système, et cibles des formulaires
d'accès/authentification et d'abonnement, rendent toujours false, ce qui
fait qu'avec des alert Javascript, j'ai vérifié que les paramètres qui
leur sont transmis, sont corrects.

Ces fonctions, rendant false, ne déclenchent pas réellemnt les urls
cibles des formulaires.

J'ai déjà implémenté cette solution de paiement Allopass, sur le site
www.lespronostics.com , que j'ai programmé entièrement, pour le
Directeur de mon site partenaire : www.lescourse.com , ceci
gratuitement, pour des raisons personnelles.

Mon propre site est : www.pronostics-courses.fr , je ne sais plus si
je l'avais déjà dit.

Je n'ai pas les moyens de rendre mon site payant pour l'instant, car
mes allocations A.A.H. et autres, sont soumises à conditions de
ressources. Elles sont diminuées plus qu'au prorata des revenus
imposables, si j'ai le moindre revenu imposable.

Alors, pour l'instant, je ne fais rien. ;)

Cependant, sur mon site, vous pouvez entendre de la musique classique
de piano, et aussi de piano et violon, des morceaux que j'ai joués
depuis 2006. ;)

La page pour ces morceaux, est accessible à partir de la page
d'accueil, en bas à droite de la page d'accueil.

Merci de me dire votre sentiment à ce sujet. ;)

Jean Francois Ortolo

unread,
Jun 28, 2012, 12:13:55 PM6/28/12
to
Le 28/06/2012 18:08, Jean Francois Ortolo a écrit :
>
> J'ai déjà implémenté cette solution de paiement Allopass, sur le site
> www.lespronostics.com , que j'ai programmé entièrement, pour le
> Directeur de mon site partenaire : www.lescourse.com , ceci
> gratuitement, pour des raisons personnelles.
>

Rebonjour

J'ai fait une erreur.

C'est www.lescourses.com , et non pas www.lescourse.com

Raahh là là làààà.. Se couucher à 4h du mat...

Tonton Th

unread,
Jun 29, 2012, 1:03:06 AM6/29/12
to
On 06/28/2012 04:26 PM, Jean Francois Ortolo wrote:

> S'il y avait des problèmes causés par des changements d'adresses ip,
> je le saurais, car il y aurait des adresses ressemblantes qui se
> suivent, en ordre chronologique.

Le répartiteur de charge me bascule de Free à Orange entre
deux pages, il se passe qui quoi ?

Jean Francois Ortolo

unread,
Jun 29, 2012, 2:52:52 AM6/29/12
to
Le 29/06/2012 07:03, Tonton Th a écrit :
> On 06/28/2012 04:26 PM, Jean Francois Ortolo wrote:
>
>> S'il y avait des problèmes causés par des changements d'adresses ip,
>> je le saurais, car il y aurait des adresses ressemblantes qui se
>> suivent, en ordre chronologique.
>
> Le répartiteur de charge me bascule de Free à Orange entre
> deux pages, il se passe qui quoi ?
>



Bonjour Monsieur

Le temps d'attente théorique, après lequel il y a prise en compte de
la modification du Javascript ( inactif -> actif, ou actif -> inactif )
pour afficher le message le cas échéant, est de 30 secondes actuellement.

.Quand Javascript est actif, la prise en compte pour le message ( ou pas
de message ), du cas où il y a une modification de la configuration des
Cookies ( acceptés -> refusés, ou refusés -> acceptés ), est
théoriquement très très courte, voire instantanée.

Je rappelle, que le but de mes manip, est de détecter
automatiquement, si Javascript est désactivé ou non, et/ou les Cookies
acceptés ou non.

Celà, pour afficher un message en haut de l'écran, suggérant
d'activer Javascript, et permettre les Cookies.

Dans ces conditions, vous pouvez faire tous les test que vous voulez,
et me dire s'il y a des cas, où le message s'affiche là où il ne devrait
pas s'afficher.

Qu'il y ait, durant 30 secondes maximum, des cas où le message ne
s'affiche pas, alors qu'il devrait s'afficher ( Javascript surtout,
et/ou les Cookies, interdits ), c'est normal : Celà vient du fait que le
visiteur vient de modifier sa configuration pour Javascript et/ou les
Cookies.

Par contre, après ce délai, si le message ne s'affiche pas dans ces
conditions, c'est qu'il y a erreur de mon site.

Donc, vous pouvez faire des tests approfondis, puis me dire si vous
obtenez des cas anormaux, indiquant une erreur du comportement de mon
site, en ce qui concerne la prise en compte de la configuration du
navigateur client.

C'est-à-dire : Le message s'affiche alors qu'il ne le devrait pas, ou
le contraire.

Celà me serait très utile que vous fassiez ces tests car moi-même, je
ne sais pas exactement quelles pourraient être, toutes les
configurations possibles de variation des adresses ip clientes, aussi
actuellement, j'ens erais plutôt, à a phase de vérification et
d'expérimentation. ;)

En ce qui me concerne, j'ai une adresse ip fixe, et une connexion
ADSL, mon site fonctionne parfaitement bien dans ces conditions.


Merci beaucoup pour vos tests.

Jean Francois Ortolo

unread,
Jun 29, 2012, 4:59:05 AM6/29/12
to
Le 29/06/2012 07:03, Tonton Th a écrit :
> On 06/28/2012 04:26 PM, Jean Francois Ortolo wrote:
>
>> S'il y avait des problèmes causés par des changements d'adresses ip,
>> je le saurais, car il y aurait des adresses ressemblantes qui se
>> suivent, en ordre chronologique.
>
> Le répartiteur de charge me bascule de Free à Orange entre
> deux pages, il se passe qui quoi ?
>


Rebonjour Monsieur

Voici théoriquement, ce qui pourrait, au pire, se passer, avec des
adresses ip changeantes, ou plusieurs adresses ip venant de la même
personne :

1- Une première requête http du client, avec l'adresse ip 1.

- Suivant que Javascript et/ou les Cookies sont interdits ou non,
le message s'affiche ou non.

2- Une deuxième requête http, du même client, avec une autre adresse
ip. 2

- Quel que soit le délai entre la première et la deuxième requête
http, le comportement est le même : Le message s'affiche ou non, de
manière normale.

Celà, en supposant, que les deux adresses ip, diffèrent par l'un des
trois premiers nombres de ces adresses ip.

Ce comportement, est du au fait que ces deux requêtes http, sont
considérées par mon site, comme deux visites différentes.


Le problème est plus compliqué, quand les deux adresses ip qui se
suivant, changent seulement par le dernier nombre d ces adresses ip.

Là, il y a deux cas :

1- La première requête http, présent l'adresse ip 1 au site, puis
change en moins d'un très petite fraction de seconde, avant que le
refresh ait pu avoir lieu.

Ce délai minimum de mon site , évidement, varie suivant les
connexion internet, plus ou moins rapide suivant la technologie
utilisée. Je l'ai fixé à 10 secondes au maximum, pour tenir compte des
connexions par modem téléphonique, qui sont, ej crois,les plus lentes.

Dans le cas ci-dessus, c'est la même adresse ip du point de vue de
mon site, puisque l'adresse ip filtrée ( = les trois premiers nombres ),
sont identiques, et elle s'est présentée il y a moins de 10 secondes,
donc de toute façon, le refresh se fait quand même ( si Javascript est
activé ), et mon site se comporte de façon normale.

2- Première requête http avec adresse ip 1.

10 secondes après, l'adresse ip n'a pas changé, donc mon site se
comporte normalement, et le refresh a lieu, si Javascript est activé.

Cs deux cas, correspondent en fait, au même cas, où l'adresse ip
filtrée ( trois prmiers nombres ), ne change pas.


Maintenant, que se passe-t-il, si deux visiteurs différents, ont des
adresses ip filtrées ( variables ou non ), identiques, et visitent en
même temps mon site ?

Cas 1 : Le premier visiteur se présente, puis le deuxième visiteur se
présente, après moins d'une fraction de seconde, c'est-à-dire avant que
le refresh du premier visiteur, ait eu la possibilité de se faire.

A ce moment-là, le premier visiteur a son refresh, si son Javascript
est activé, et mon site se comporte de manière normale.

Le deuxième visiteur, a aussi son refresh ( si Javascript est activé
), et tout est correct.


Cas 2- Le premier visiteur se présente, pus le deuxième visiteur se
présente, après que le refresh éventuel du premier visiteur ait eu lieu
( suivant que Javascript soit activé ou non pour le premier visiteur )

Les deux visiteurs sot considérés comme le même visiteur par mon
site, car leurs adresses ip filtrées sont les mêmes.

A ce moment-là, le deuxième visiteur n'a pas la variable de session
$_SESSION['js'] alimentée, donc son refresh se fait quand même, et mon
site répond de façon normale.


Tout ceci, dépend du fait, que la variable de session ne soit pas
encore alimentée, car c'est la première requête http, pour chacun de ces
deux visiteurs.

Si cette variable de session a déjà été alimentée, quel que soit le
visiteur, c'est que Javasript est activé, et que c'est au moins la
deuxième requête http faite par le visiteur.

Dans le Cas 1, le premier visiteur a sa variable de session alimentée
donc son refresh ne se fait pas, mais il n'y a pas de problème, si le
délai de 30 secondes depuis la première requête http, n'est pas dépassé.

En effet, mon site économise les refresh, en ne faisant pas de
refresh pour la même visite, si ce délai de 30 secondes n'est pas dépassé.

Dans le cas contraire, le message s'affiche, alors que son Javascript
est activé.

Le Cas 2 est identique au cas 1, de ce point de vue.


Donc, s'il y a plusieurs visiteurs d'adresse ip filtrée identique, et
que ceux-ci font des requêtes http alternées, dans des délais de moins
de 30 secondes, le visiteur ayant fait la requête http trop rapidement,
voit son message s'afficher.

Je n'ai pas d'autre alternative, pour limiter ces cas, qui devraient
être rares, de baisser le délai de 30 secondes, à moins que 30 secondes.

Mais à ce moment-là, il risquerait d'y avoir un refresh à chaque page
chargée, ce que je cherche à éviter.

En ce qui concerne les adresses ip entières identiques ( fixes ou
variables ), le problème est strictement identique cas ci-dessus, des
adresses ip filtrées identiques.

Merci beaucoup de vos tests.

Jean Francois Ortolo

unread,
Jun 29, 2012, 5:06:48 AM6/29/12
to

Rebonjour Monsieur

Il y a probablement quelques erreurs d'inattention dans ma réponse
ci-dessus, donc vos tests feront foi. ;)

Jean Francois Ortolo

unread,
Jun 29, 2012, 3:05:00 PM6/29/12
to


Bonsoir Monsieur

J'ai modifié, la prise en compte des adresses ip, servant de repère
pour savoir si c'est le premier chargement d'une page, ou le deuxième
chargement ( le refresh Javascript ).

D'autre part, je ne fais plus d'économie des refresh. Donc, à chaque
fois qu'un visiteur veut charger une page, et qu'il a Javascript activé,
il y a un refresh.

Si je faisais autrement, il y aurait parfois des affichages
intempestifs du message, même si Javascript et les Cookies sont actifs.

J'ai ramené le délai maximal théorique de chargement d'une page (
premier chargement ), à 7 secondes.

Celà évite, qu'après avoir atterri sur une page, le visiteur charge
lui-même de nouveau une page ( la même ou une autre ), en moins de temps
que ce délai accepté de chargement d'une page, ce qui aurait pour effet,
que ce nouveau chargement de page, ne sot pas suivi de refresh, et que
le message s'affiche quand même, bien que Javascript soit activé.

Avec ce délai fixé à 10 secondes,j'ai constaté moi-même ce problème,
donc j'ai ramené ce délai à 7 secondes.

Je vous laisse juge.

Si vous avez une ip fixe, et Javascript activé, arrivez-vous à
charger deux pages, suffisamment rapidement, pour que ce message
s'affiche quand même ?

En ce qui me concerne, je n'y suis pas arrivé.

Peut-être avec une connexion fibre... ;)

J'ai constaté, que les bots de Google, se suivent rapidement sur mon
site, ( délais > 7 secondes quand même... ;) ), avec des adresses ip
différentes, et n'ont pas Javascript activé, ce qui semble logique.

Ce délai de 7 secondes, vous semble-t-il suffisant, même pour des
connexions internet très lentes ?

Je vais probablement prochainement, installer un formulaire de
contact sur mon site, ce qui permettra mieux à mes visiteurs, de me
donner leurs avis sur les fonctionnalités de mon site.

Normalement,si ce délai de 7 secondes est dépassé par des connexions
internet lentes, le seul effet serait un affichage du message à chaque
page visitée, même si Javascript est activé.

Dans un contexte d'accès théorique futur payant à mon site, il serait
impossible, dans ces conditions, à ces visiteurs, de payer ou de
s'authentifier.

Merci beaucoup de vos réponses.

Jean Francois Ortolo

unread,
Jun 29, 2012, 3:14:41 PM6/29/12
to
Le 29/06/2012 21:05, Jean Francois Ortolo a écrit :
>
>
> Bonsoir Monsieur
>
> J'ai modifié, la prise en compte des adresses ip, servant de repère
> pour savoir si c'est le premier chargement d'une page, ou le deuxième
> chargement ( le refresh Javascript ).
>


Beuh...

J'ai oublié de dire : je prend maintenant en compte, les adresses ip
entières, et non plus filtrées, comme avant.

Merci de me dire si vos tests montrent des erreurs de mon site.

Une erreur pourrait être : Le message s'affiche, alors qu'il ne
devrait pas s'afficher. ( si Javascript est activé, et les Cookies permis ).

Le contraire, peut se produire de manière temporaire, si Javascript
était activé, puis ne l'est plus.

Celà peut arriver, pendant au plus 3O secondes après avoir désactivé
Javascript.

Si ce délai est dépassé, c'est une erreur. ;)

Ce sont les seules erreurs détectables.

Merci beaucoup de vos réponses.

Jean François Ortolo



SAM

unread,
Jun 30, 2012, 11:46:21 AM6/30/12
to
Le 25/06/12 17:50, Jean Francois Ortolo a écrit :
>
>
> Bonjour Monsieur ;)

oui, oui, bonjour, bonsoir !
mesdames, mesdemoiselles, messieurs,
chers lectrices et lecteurs,
évenanzendonkofète

> Dans ma terminologie, et pour mes besoins actuels de cette application,
> une adresse ip variable, est une adresse qui peut varier au cours de la
> navigation d'un visiteur sur mon site.

On n'en a rien à faire des adresses IP (quelle qu'elles soient)
et ça a déjà été dit
---> il y a ici chez moi entre 1 à 5 ordis
---> la seule IP que ton serveur verra est celle de la box
<--- donc ça ne peut t'être utile

Hop !
zapping général de toutes circonvolutions autour du sujet "IP"

soit tu te contentes de la gestion de session(s) suivant PHP
soit tu te bases sur les cookies (de session ?) en donnant un nom(*)
aléatoire au visiteur s'il n'en a pas déjà eu un d'attribué.

(*) ça peut tout aussi bien être son "vrai" nom ou pseudo s'il s'est
inscrit préalablement (ou logué) et a été enregistré en BdD.
(ou l'ID correspondant au pseudo dans la table des adhérents)

> Par ailleurs, celà non plus n'est pas important, car si le visiteur
> dépasse ce délai maximal, la page chargée ensuite, sera seulement
> chargée deux fois, avec un refresh, car le visiteur sera simplement
> considéré comme un autre visiteur.
>
> Et ceci, seulement si son adresse ip, varie.

Ben non ...
- le gus accepte les cookies (obligatoirement !)
- le cookie du gus est connu (nouveau ou ancien est-ce important ?)
- accessoirement (bien qu'on ne sache plus/pas pourquoi) si à la page
suivante le délai est dépassé on la recharge

> J'identifie que c'est le même visiteur, avec des infos de session. Très
> bien.
>
> Et si les cookies sont refusés ? Alors à chaque fois c'est un nouveau

non, comme chez d'autres(*), si les cookies sont refusés hop! pas de
pronostic et vavoirayeur

(*) comment est mis à jour le "panier" sur les sites marchands ?
(alors qu'on ne s'est pas encore logué !)

> visiteur, donc c'est le premier chargement de la page, donc il y a un
> refresh systématique et répétitif sans fin, si les cookies sont refusés ?

non, si pas de cookie hop! on envoie la page (ou l'extrait) indiquant
que les cookies sont obligatoires
et ...
... bien sûr
pas de JS de refresh

> J'avoue que ce que je pourrais faire, lors du premier chargement, serait
> de faire le refresh ( donc, deuxième chargement de la page en mode
> Javascript ), avec le protocole get, et un paramètre qui s'il existe, me
> servirait à savoir que c'est le deuxième chargement.

les cookies peuvent t'informer de tout ça quoi tu veux (à condition de
les avoir créés)

- le cookie "nom" existe ? oui: on le lit, non: on le crée
- le cookie "date" existe ? oui: on le lit, non: on le crée

ensuite on agit en fonction et remet à jour le cookie "date"

(zap zip zop!)

> Je ne pourrais le savoir, que si le visiteur accepte les Cookies... ;(

voui

> Si le visiteur n'accepte pas les Cookies, problème insoluble ?

le visiteur *doit* les accepter épicétou

> Dans ce cas, un refresh obligatoire à chaque page ?

que de gâchis !


--
Stéphane Moriaux avec/with iMac-intel

* Unknown - détecté
* Anglais
* Français
* Espagnol

* Anglais
* Français
* Espagnol

<javascript:void(0);>

SAM

unread,
Jun 30, 2012, 2:24:36 PM6/30/12
to
Le 25/06/12 23:39, Jean Francois Ortolo a écrit :
>
> Quant au reste du nouvel algorithme que Monsieur Miakinen m'a suggéré,
> et qui est effectivement beaucoup plus performant que le mien, je n'ai
> besoin pour passer à la programmation, que de savoir comment traiter le
> cas où Javascript est activé, et les Cookies refusés.

On suppose que le PHP arrive à voir qu'il n'y a pas de cookies.
Il y a alors un JS dans le head qui fait immédiatement rafraichir vers
la page avec les scripts JS nécessaires

Si pas de cookie ni de JS alors on reste sur la page là (qui ne montre
peut-être qu'un message réclamant cookies et/ou JS)

> Comment, dans ce cas-là, savoir si le visiteur qui visite votre page peu
> de temps après une première visite sur une page (la même ou une autre,
> peu importe ), est bien passé sur le site il y a très peu de temps ?

On l'sait pas (sauf si session PHP)
et alors ? est-ce grave ? et en quoi ?

> Comment, sans les Cookies, transformer en gros, le protocole HTTP, qui
> ne mémorise pas les accès http, en protocole avec mémoire ?

on peut (parfois) savoir de quelle page(url) le visiteur vient

referer ? (ça n'existe pas en PHP ?)

> Je ne demande pas le feu, simplement une mémoire très courte, de
> quelques secondes.
>
> 30 secondes me suffirait.
>
> Celà me permettrait, de ne pas faire de refresh si le délai depuis le
> dernier chargement manuel d'une page sur mon site ( n'importe laquelle
> ), est inférieur à 30 secondes.

Heu ... tu veux vraiment faire recharger chaque page toutes les 30
secondes ?

meta refresh ???

SAM

unread,
Jun 30, 2012, 2:33:54 PM6/30/12
to
Le 26/06/12 11:57, Olivier Miakinen a écrit :
>
> Une autre consiste à créer un formulaire avec champs hidden, dont la
> soumission est lancée par JavaScript. Ainsi, non seulement tu as ton
> refresh, tu vérifies au passage que JavaScript fonctionne (si le
> bouton est invisible et n'est accessible que par JS), et il n'y a
> aucun paramètre passé dans l'url (c'est dans les champs hidden).

"hidden" n'a rien à voir avec les paramètres passés en url
c'est le mode GET ou POST qui fait la différence
- GET : visible
- POST : invisible
(savoir si Google interprète et retient l'url "get" ?)
les champs peuvent donc être normaux (text ou password)

> Ouf !

anéfé !

SAM

unread,
Jun 30, 2012, 2:47:10 PM6/30/12
to
Le 27/06/12 13:18, Jean Francois Ortolo a écrit :
>
> Est-ce possible, que plusieurs visiteurs avec la même adresse ip ,
> visitent mon site strictement en même temps, à 30 secondes près ?

ce ne doit pas être courant mais pas impossible

Mon fils et moi, qui partageons la même box-adsl, pouvons tt à fait et
soudainement nous intéresser et nous passionner pour les courses de
chevaux (et les paris !!!) par exemple, et donc aller sur ce site en
même temps y cliquoter frénétiquement.
Et si jamais mon épouse et ma fille s'y mettent, je te dis pas !

il faut (normalement) s'en tenir à la 2ième partie : "possible oui"

donc KKboudin, on jette !

> J'ai mis en place, l'enregistrement dans la table MySQL CONNEXION, de
> toutes les adresses ip datant de moins de 35 jours.

Oui, et ?

> Du moins, j'ai d'abord pris les adresses ip entières ( c'est de l'ip4,
> apparemment personne de mes visiteurs n'est en ip6 ), mais j'ai constaté
> qu'il y avait des adresses très similaires qui se suivaient de manière
> rapprochée en ordre chronologique.

et ???

Je n'arrive pas à comprendre l’intérêt de la chose ... mébon.

SAM

unread,
Jun 30, 2012, 3:04:14 PM6/30/12
to
Le 28/06/12 18:08, Jean Francois Ortolo a écrit :
> Le 28/06/2012 16:57, Olivier Miakinen a écrit :
>> Bonjour,
>>
>> À l'occasion, tu voudras bien nous expliquer (en langage courant,
>> pas en terme de PHP et SQL) ce qu'est censé apporter ce système de
>> doubles requêtes ?
>>
>> Cordialement,
>>
>
>
>
> Bonjour Monsieur
>
> L'intérêt, est de détecter si le navigateur client, a Javascript activé

ça, ça se fait de la manière suivante :
on envoie une page qui doit fonctionner sans JS
et si le JS est activé il saura y lire une redirection JS vers la page
supposée fonctionner en JS (ça se fait avant même de charger tte la page)

> ou non, e/ou les Cookies acceptés ou non.

Bon, là le PHP doit y arriver ;-)

> Si l'un de deux, ou les deux, sont interdits, alors un message s'affiche
> en haut de l'écran de pratiquement toutes les pages de mon site,
> indiquant qu'il est souhaitable d'activer Javascript,et de permettre les
> Cookies.
>
> Je ne distingue pas, les deux possibilités de Javascript et des Cookies,
> et le message est le même dans tous les cas où ce message apparaît.

sauf que ... il est tt à fait possible que seuls les cookies soient
nécessaires

alors on demande aux visiteurs de les activer et puis voilà !


> Pour l'instant, je n'ai pas besoin de celà, mais à terme, si je rend mon
> site payant, le système de paiement Allopass ( que j'ai déjà programmé
> sur mon site, mais n'est pas actif ), nécessite que Javascript soit
> activé, et les Cookies acceptés.

bon ... alors on fait tout ça en JS et hop!
(Le JS peut aussi voir/modifier/créer les cookies)

SAM

unread,
Jun 30, 2012, 3:08:57 PM6/30/12
to
Le 29/06/12 21:14, Jean Francois Ortolo a écrit :
>
> Le contraire, peut se produire de manière temporaire, si Javascript
> était activé, puis ne l'est plus.
>
> Celà peut arriver, pendant au plus 3O secondes après avoir désactivé
> Javascript.

mézenfin !
si on a averti que le visiteur-parieur doit avoir le JS !
il est débile ou quoi d'alors le désactiver n'importe quand ? !

S'il désactive c'est qu'il s'en fout et ne compte pas rester sur le
site, non ?

Paul Gaborit

unread,
Jun 30, 2012, 5:15:23 PM6/30/12
to

À (at) Sat, 30 Jun 2012 21:08:57 +0200,
SAM <stephanemor...@wanadoo.fr.invalid> écrivait (wrote):
Ou peut-être a-t-il un faux contact dans son navigateur qui
active/désactive le javascript par à coup...

SAM

unread,
Jul 1, 2012, 5:05:43 AM7/1/12
to
Le 30/06/12 23:15, Paul Gaborit a écrit :
Alors ... je ne vois plus que le recours à un électricien !

Quel navigateur pourrait avoir ce problème ?

Michek TRonui

unread,
Nov 26, 2021, 5:07:48 AM11/26/21
to
J'avais un problème moi aussi avec la page du site https://www.boturfers.fr/quinte-du-jour qui est en AMP (je me suis renseigné c'est du cache stocké chez Google) mais avec la maj de Chrome c'est bon maintenant.
0 new messages