Je détecte automatiquement si Javascript est activé
53 réponses
Jean Francois Ortolo
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.
À (at) Tue, 26 Jun 2012 11:57:57 +0200, Olivier Miakinen <om+ é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 - <http://perso.mines-albi.fr/~gaborit/>
À (at) Tue, 26 Jun 2012 11:57:57 +0200,
Olivier Miakinen <om+news@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 - <http://perso.mines-albi.fr/~gaborit/>
À (at) Tue, 26 Jun 2012 11:57:57 +0200, Olivier Miakinen <om+ é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 - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo é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/>
À (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo
<ortolo.jeanfrancois_nospam@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/>
À (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo é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
Le 26/06/2012 22:48, Paul Gaborit a écrit :
À (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo é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
Le 26/06/2012 22:48, Paul Gaborit a écrit :
À (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo
<ortolo.jeanfrancois_nospam@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.
À (at) Tue, 26 Jun 2012 13:21:43 +0200, Jean Francois Ortolo é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
À (at) Wed, 27 Jun 2012 03:05:57 +0200, Jean Francois Ortolo é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.
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 27 Jun 2012 03:05:57 +0200,
Jean Francois Ortolo <ortolo.jeanfrancois_nospam@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.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
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... ;)
Bien amicalement.
Jean François Ortolo
Jean Francois Ortolo
Le 27/06/2012 09:55, Paul Gaborit a écrit :
À (at) Wed, 27 Jun 2012 03:05:57 +0200, Jean Francois Ortolo é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
Le 27/06/2012 09:55, Paul Gaborit a écrit :
À (at) Wed, 27 Jun 2012 03:05:57 +0200,
Jean Francois Ortolo <ortolo.jeanfrancois_nospam@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.
À (at) Wed, 27 Jun 2012 03:05:57 +0200, Jean Francois Ortolo é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
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.
Bien amicalement.
Jean François Ortolo
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.
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.
Bien amicalement.
Jean François Ortolo
Paul Gaborit
À (at) Wed, 27 Jun 2012 11:05:17 +0200, Jean Francois Ortolo é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 - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 27 Jun 2012 11:05:17 +0200,
Jean Francois Ortolo <ortolo.jeanfrancois_nospam@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 - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 27 Jun 2012 11:05:17 +0200, Jean Francois Ortolo é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 - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Wed, 27 Jun 2012 13:18:51 +0200, Jean Francois Ortolo é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).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 27 Jun 2012 13:18:51 +0200, Jean Francois Ortolo
<ortolo.jeanfrancois_nospam@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).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Wed, 27 Jun 2012 13:18:51 +0200, Jean Francois Ortolo é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).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Jean Francois Ortolo
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.
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... ;)
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... ;)
