Je détecte automatiquement si Javascript est activé

Olivier Miakinen

25/06/2012 à 12:59

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

;-)

Cordialement,
--
Olivier Miakinen

Jean Francois Ortolo

25/06/2012 à 17:50

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.

Bien amicalement.

Jean François Ortolo

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.

Bien amicalement.

Jean François Ortolo

Vous avez filtré cet utilisateur ! Consultez son message

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.

Bien amicalement.

Jean François Ortolo

Paul Gaborit

25/06/2012 à 18:13

À (at) Mon, 25 Jun 2012 12:59:59 +0200,
Olivier Miakinen <om+ é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

25/06/2012 à 19:11

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.

--

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

Jean Francois Ortolo

25/06/2012 à 23:39

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

Merci beaucoup de vos réponses.

Bien amicalement.

Jean François Ortolo

Olivier Miakinen

26/06/2012 à 01:40

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

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

Vous avez filtré cet utilisateur ! Consultez son message

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

26/06/2012 à 08:31

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

Vous avez filtré cet utilisateur ! Consultez son message

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

26/06/2012 à 11:57

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

26/06/2012 à 12:16

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

26/06/2012 à 13:21

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.

Très amicalement. ;)

Jean François Ortolo

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.

Très amicalement. ;)

Jean François Ortolo

Vous avez filtré cet utilisateur ! Consultez son message

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.

Très amicalement. ;)

Jean François Ortolo

Je détecte automatiquement si Javascript est activé

10 réponses

Veuillez sélectionner un problème