J'aurais besoin ( pas tout de suite mais je prévois ), d'assurer sur
une partie de mon site, l'authentification des visiteurs, à ces conditions:
- J'impose à tous mes visiteurs de supporter les cookies,
- Je peux donc faire une reconnaissance du visiteur, par un cookie
permanent, et son adresse ip, mais,
- J'accepte les visiteurs abonnés à AOL, dont c'est connu que
l'adresse ip change régulièrement en cours de connexion,
- J'accepte les visiteurs connectés par modem RTC, ou dont l'adresse
ip personnelle, n'est pas toujours la même, pour le même visiteur.
A ces conditions, qui me semble obligatoires, quel serait le moyen
dont je disposerais, en PHP, pour authentifier mes visiteurs, sachant
que je cherche également, à mesurer le temps de parcours de chaque
visiteur, sur tous les scripts PHP appartenant à un répertoire donné
fixé ( les Courses Nouvelles sur mon site ), et qui serait donc le
répertoire:
php/courses_nouvelles/
Evidemment, le but est, de mesurer ce temps d'utilisation des Courses
Nouvelles sur mon site, pour limiter son accès gratuit, au delà duquel,
le visiteur, ayant passé globalement son temps maxi d'accès gratuit,
devra payer pour poursuivre son utilisation.
Je suppose que, pour suivre le parcours du visiteur, il faudra un
identifiant de session, mais est-ce possible pour un abonné AOL, dont
l'adresse ip change en cours de connexion ? :(
Merci beaucoup de vos suggestions.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
antoine
Bonjour Jean-Francois
J'aurais besoin ( pas tout de suite mais je prévois ), d'assurer sur une partie de mon site, l'authentification des visiteurs, à ces conditions: [...]
A mon avis, regarde les solutions de type identifiant/mot_de_passe à base de variables de session. Elles ont le mérite d'être plus indépendantes du client. Un tutorial parmi d'autres :
http://www.phpdebutant.org/article47.php
-- Antoine
Bonjour Jean-Francois
J'aurais besoin ( pas tout de suite mais je prévois ), d'assurer sur
une partie de mon site, l'authentification des visiteurs, à ces conditions:
[...]
A mon avis, regarde les solutions de type identifiant/mot_de_passe à
base de variables de session. Elles ont le mérite d'être plus
indépendantes du client. Un tutorial parmi d'autres :
J'aurais besoin ( pas tout de suite mais je prévois ), d'assurer sur une partie de mon site, l'authentification des visiteurs, à ces conditions: [...]
A mon avis, regarde les solutions de type identifiant/mot_de_passe à base de variables de session. Elles ont le mérite d'être plus indépendantes du client. Un tutorial parmi d'autres :
http://www.phpdebutant.org/article47.php
-- Antoine
Jean-Francois Ortolo
antoine wrote:
Bonjour Jean-Francois
A mon avis, regarde les solutions de type identifiant/mot_de_passe à base de variables de session. Elles ont le mérite d'être plus indépendantes du client. Un tutorial parmi d'autres :
http://www.phpdebutant.org/article47.php
Bonjour
Effectivement, la solution présentée par ce lien, donne un exemple d'authentification associée à une mémorisation par session durant la navigation du visiteur sur le site. Mais il y a quelques problèmes:
- Cà marche parce que le nom de la variable de session est connu, et sa valeur assure l'authentification. Mais si ( pour plus de sécurité ), l'identificateur de session devait être crypté, comment faire pour sélectionner le bon couple login/password à partir de la database, pour comparer la valeur cryptée du login, à celle de la variable de session ?
- Cà marche, si et seulement si le visiteur a déjà un login/password, mais rien ne l'empêche ( s'il y a intérêt ), de faire semblant de ne pas avoir de login, et à redemander ( ou fournir ) un nouveau couple login/password.
Il pourrait y avoir intérêt en particulier ( c'est mon cas ), si ce login/password l'identifierait comme ayant déjà passé un certain temps/nombre de fois sur la partie protégée de mon site, après quoi il devrait payer pour continuer ses visites.
Donc, en conclusion, je pense ( détrompez-moi si j'ai faux ), que la seule solution, pour identifier un visiteur ayant intérêt à paraître comme nouveau visiteur, serait de l'identifier ( de manière sûre de préférence ), d'après ses données de connexion...
...Et là, problème: L'adresse ip ne suffit pas, car elle peut être commune à plusieurs visiteurs différents à des moments différents, et elle peut changer pour le même visiteur, suivant le moment... Donc je suis dans la mouise, car je suis incapable d'identifier de manière sûre mes visiteurs.
Monsieur John Gallet dirait ( Il me semble qu'il l'a déjà dit ), qu'il est totalement impossible d'identifier un visiteur par son adresse ip, ni par un autre moyen si le visiteur ne le souhaite pas précisément.
Dont acte: Je suis mal barré.
Conclusion: Je ne peux pas offrir une "période d'essai" à mes visiteurs c'est comme ça et pas autrement.
mdr
Et... Pour les Adsense, comme procède Google, pour identifier les visiteurs ayant cliqués, qui sont précidément, le propriétaire des Adsense de son site ? Ce serait intéressant à creuser.
Bien à vous.
Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
antoine wrote:
Bonjour Jean-Francois
A mon avis, regarde les solutions de type identifiant/mot_de_passe à
base de variables de session. Elles ont le mérite d'être plus
indépendantes du client. Un tutorial parmi d'autres :
http://www.phpdebutant.org/article47.php
Bonjour
Effectivement, la solution présentée par ce lien, donne un exemple
d'authentification associée à une mémorisation par session durant la
navigation du visiteur sur le site. Mais il y a quelques problèmes:
- Cà marche parce que le nom de la variable de session est connu, et
sa valeur assure l'authentification. Mais si ( pour plus de sécurité ),
l'identificateur de session devait être crypté, comment faire pour
sélectionner le bon couple login/password à partir de la database, pour
comparer la valeur cryptée du login, à celle de la variable de session ?
- Cà marche, si et seulement si le visiteur a déjà un login/password,
mais rien ne l'empêche ( s'il y a intérêt ), de faire semblant de ne
pas avoir de login, et à redemander ( ou fournir ) un nouveau couple
login/password.
Il pourrait y avoir intérêt en particulier ( c'est mon cas ), si ce
login/password l'identifierait comme ayant déjà passé un certain
temps/nombre de fois sur la partie protégée de mon site, après quoi il
devrait payer pour continuer ses visites.
Donc, en conclusion, je pense ( détrompez-moi si j'ai faux ), que la
seule solution, pour identifier un visiteur ayant intérêt à paraître
comme nouveau visiteur, serait de l'identifier ( de manière sûre de
préférence ), d'après ses données de connexion...
...Et là, problème: L'adresse ip ne suffit pas, car elle peut être
commune à plusieurs visiteurs différents à des moments différents, et
elle peut changer pour le même visiteur, suivant le moment... Donc je
suis dans la mouise, car je suis incapable d'identifier de manière sûre
mes visiteurs.
Monsieur John Gallet dirait ( Il me semble qu'il l'a déjà dit ),
qu'il est totalement impossible d'identifier un visiteur par son adresse
ip, ni par un autre moyen si le visiteur ne le souhaite pas précisément.
Dont acte: Je suis mal barré.
Conclusion: Je ne peux pas offrir une "période d'essai" à mes
visiteurs c'est comme ça et pas autrement.
mdr
Et... Pour les Adsense, comme procède Google, pour identifier les
visiteurs ayant cliqués, qui sont précidément, le propriétaire des
Adsense de son site ? Ce serait intéressant à creuser.
Bien à vous.
Amicalement.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com
A mon avis, regarde les solutions de type identifiant/mot_de_passe à base de variables de session. Elles ont le mérite d'être plus indépendantes du client. Un tutorial parmi d'autres :
http://www.phpdebutant.org/article47.php
Bonjour
Effectivement, la solution présentée par ce lien, donne un exemple d'authentification associée à une mémorisation par session durant la navigation du visiteur sur le site. Mais il y a quelques problèmes:
- Cà marche parce que le nom de la variable de session est connu, et sa valeur assure l'authentification. Mais si ( pour plus de sécurité ), l'identificateur de session devait être crypté, comment faire pour sélectionner le bon couple login/password à partir de la database, pour comparer la valeur cryptée du login, à celle de la variable de session ?
- Cà marche, si et seulement si le visiteur a déjà un login/password, mais rien ne l'empêche ( s'il y a intérêt ), de faire semblant de ne pas avoir de login, et à redemander ( ou fournir ) un nouveau couple login/password.
Il pourrait y avoir intérêt en particulier ( c'est mon cas ), si ce login/password l'identifierait comme ayant déjà passé un certain temps/nombre de fois sur la partie protégée de mon site, après quoi il devrait payer pour continuer ses visites.
Donc, en conclusion, je pense ( détrompez-moi si j'ai faux ), que la seule solution, pour identifier un visiteur ayant intérêt à paraître comme nouveau visiteur, serait de l'identifier ( de manière sûre de préférence ), d'après ses données de connexion...
...Et là, problème: L'adresse ip ne suffit pas, car elle peut être commune à plusieurs visiteurs différents à des moments différents, et elle peut changer pour le même visiteur, suivant le moment... Donc je suis dans la mouise, car je suis incapable d'identifier de manière sûre mes visiteurs.
Monsieur John Gallet dirait ( Il me semble qu'il l'a déjà dit ), qu'il est totalement impossible d'identifier un visiteur par son adresse ip, ni par un autre moyen si le visiteur ne le souhaite pas précisément.
Dont acte: Je suis mal barré.
Conclusion: Je ne peux pas offrir une "période d'essai" à mes visiteurs c'est comme ça et pas autrement.
mdr
Et... Pour les Adsense, comme procède Google, pour identifier les visiteurs ayant cliqués, qui sont précidément, le propriétaire des Adsense de son site ? Ce serait intéressant à creuser.
Bien à vous.
Amicalement.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Demosthene
J'aurais besoin ( pas tout de suite mais je prévois ), d'assurer sur une partie de mon site, l'authentification des visiteurs, à ces conditions:
- J'impose à tous mes visiteurs de supporter les cookies, - Je peux donc faire une reconnaissance du visiteur, par un cookie permanent, et son adresse ip,
Rares seront tes visiteurs qui auront un ip fixe entre deux connexions. Garde autre chose dans le cookie et crypte le si tu le souhaites.
Reviens nous voir quand tu commenceras :)
Cordialement
Démosthène
J'aurais besoin ( pas tout de suite mais je prévois ), d'assurer sur
une partie de mon site, l'authentification des visiteurs, à ces conditions:
- J'impose à tous mes visiteurs de supporter les cookies,
- Je peux donc faire une reconnaissance du visiteur, par un cookie
permanent, et son adresse ip,
Rares seront tes visiteurs qui auront un ip fixe entre deux connexions.
Garde autre chose dans le cookie et crypte le si tu le souhaites.
J'aurais besoin ( pas tout de suite mais je prévois ), d'assurer sur une partie de mon site, l'authentification des visiteurs, à ces conditions:
- J'impose à tous mes visiteurs de supporter les cookies, - Je peux donc faire une reconnaissance du visiteur, par un cookie permanent, et son adresse ip,
Rares seront tes visiteurs qui auront un ip fixe entre deux connexions. Garde autre chose dans le cookie et crypte le si tu le souhaites.
Reviens nous voir quand tu commenceras :)
Cordialement
Démosthène
John GALLET
Bonjour,
- Cà marche parce que le nom de la variable de session est connu, et sa valeur assure l'authentification.
On va avoir du mal à faire autrement. Si on veut récupérer "quelque chose" côté serveur, il faut bien qu'on sache *où* on va le récupérer. Que ce soit dans $_REQUEST['id_session'], dans $PHP_SESSION_ID, dans $_COOKIES['pouetpouet'], peu importe, mais il faut bien qu'on sache où on va le récupérer.
l'identificateur de session devait être crypté, comment faire pour sélectionner le bon couple login/password à partir de la database, pour comparer la valeur cryptée du login, à celle de la variable de session ?
L'id_session contient n'importe quoi du moment que c'est impossible à deviner de l'extérieur par un attaquant. Il n'est pas nécessairement bon d'y inclure le login, chiffré ou non. Cf le chapitre sur les sessions (le chap. 10 je crois) du cours que je diffuse sur www.saphirtech.fr pour plus de détails sur une implémentation manuelle possible (et comprendre les principes même si on utilise ensuite les sessions natives).
- Cà marche, si et seulement si le visiteur a déjà un login/password, mais rien ne l'empêche ( s'il y a intérêt ), de faire semblant de ne pas avoir de login, et à redemander ( ou fournir ) un nouveau couple login/password. Tout à fait. En fait il y a deux problème bien distincts :
1) au cours d'une "même session" (on va dire pour simplifier : un intervalle de 10 minutes) savoir que la même souris a cliqué sur X pages. Pour ceci, les sessions sont une (bonne) solution. Que ce soit les sessions natives PHP ou autre d'ailleurs.
2) complètement autre problème : sachant qu'un clic de souris a été généré, est-ce que c'est la même souris que la semaine dernière (je suppose ici une utilisation poste mono-utilisateur) ? Là dessus il n'y a que deux solutions : ou on conserve un état côté serveur et on compte sur la bonne volonté de l'utilisateur (on l'appâte avec un service en plus par exemple) pour se faire reconnaître par son login+pass, ou alors on conserve la trace côté client (cookie). Il n'y a pas d'autres solutions. Dans les solutions côté client, on peut avoir une application java ou autre (php-gtk, tiens par exemple !) qui va essayer de pourrir la base de registres ou autre, mais il faudra bien stocker l'information sur la machine locale.
Il pourrait y avoir intérêt en particulier ( c'est mon cas ), si ce login/password l'identifierait comme ayant déjà passé un certain temps/nombre de fois sur la partie protégée de mon site, après quoi il devrait payer pour continuer ses visites. Oui. Si le but est de faire du preview gratuit limité dans le temps, on
ne peut compter que sur une validation manuelle des demandes de preview pour essayer de détecter les "fraudeurs", et une limitation des prestations pour encourager l'upgrade. Par exemple, ne donner les stats que sur 1 mois et non 6 mois.
Donc, en conclusion, je pense ( détrompez-moi si j'ai faux ), que la seule solution, pour identifier un visiteur ayant intérêt à paraître comme nouveau visiteur, serait de l'identifier ( de manière sûre de préférence ), d'après ses données de connexion...
Si on pouvait, oui, mais comment ferez vous pour m'identifier alors que je suis, dans une même semaine, chez 5 ou 6 clients différents ? Passé un temps, et cela avait fait un tollé général, INTEL avait voulu embarquer des identifiants uniques dans chaque µp... Cela aurait été un début de solution (début hein, parce que comme on peut envoyer n'importe quoi au serveur dès lors que ça vient du client...)
...Et là, problème: L'adresse ip ne suffit pas, car elle peut être commune à plusieurs visiteurs différents à des moments différents, et elle peut changer pour le même visiteur, suivant le moment... Et même pire que ça, vous ne pouvez pas la connaître avec certitude de
toutes façons.
Monsieur John Gallet dirait ( Il me semble qu'il l'a déjà dit ), qu'il est totalement impossible d'identifier un visiteur par son adresse ip, ni par un autre moyen si le visiteur ne le souhaite pas précisément. Il l'a dit (et il le répète, vous pouvez laisser tomber le "monsieur"
;-)..). Quelqu'un qui a intérêt à truander y arrivera toujours dans ce contexte.
Dont acte: Je suis mal barré. il faut transformer la motivation de l'internaute pour qu'il ait intérêt
à conserver son identification et non intérêt à la perdre.
Conclusion: Je ne peux pas offrir une "période d'essai" à mes visiteurs c'est comme ça et pas autrement. Si, mais sur des fonctionnalités restreintes pour encourager l'upgrade.
Avec une limitation dans le temps de cette période et une validation manuelle des demandes. Ca forcera au moins le "petit malin" à ouvrir une autre boite email et être créatif (on joue sur la lassitude dudit malin, c'est tout). Enfin la nouvelle boite mail, il suffit d'un UNIQUE bien placé en sgbd, pas besoin de la validation manuelle pour ça.
Et... Pour les Adsense, comme procède Google, pour identifier les visiteurs ayant cliqués, qui sont précidément, le propriétaire des Adsense de son site ?
C'est truandable, mais là aussi il faut voir les enjeux.
a++; JG
Bonjour,
- Cà marche parce que le nom de la variable de session est connu, et
sa valeur assure l'authentification.
On va avoir du mal à faire autrement. Si on veut récupérer "quelque
chose" côté serveur, il faut bien qu'on sache *où* on va le récupérer.
Que ce soit dans $_REQUEST['id_session'], dans $PHP_SESSION_ID, dans
$_COOKIES['pouetpouet'], peu importe, mais il faut bien qu'on sache où
on va le récupérer.
l'identificateur de session devait être crypté, comment faire pour
sélectionner le bon couple login/password à partir de la database, pour
comparer la valeur cryptée du login, à celle de la variable de session ?
L'id_session contient n'importe quoi du moment que c'est impossible à
deviner de l'extérieur par un attaquant. Il n'est pas nécessairement bon
d'y inclure le login, chiffré ou non. Cf le chapitre sur les sessions
(le chap. 10 je crois) du cours que je diffuse sur www.saphirtech.fr
pour plus de détails sur une implémentation manuelle possible (et
comprendre les principes même si on utilise ensuite les sessions natives).
- Cà marche, si et seulement si le visiteur a déjà un login/password,
mais rien ne l'empêche ( s'il y a intérêt ), de faire semblant de ne
pas avoir de login, et à redemander ( ou fournir ) un nouveau couple
login/password.
Tout à fait. En fait il y a deux problème bien distincts :
1) au cours d'une "même session" (on va dire pour simplifier : un
intervalle de 10 minutes) savoir que la même souris a cliqué sur X
pages. Pour ceci, les sessions sont une (bonne) solution. Que ce soit
les sessions natives PHP ou autre d'ailleurs.
2) complètement autre problème : sachant qu'un clic de souris a été
généré, est-ce que c'est la même souris que la semaine dernière (je
suppose ici une utilisation poste mono-utilisateur) ? Là dessus il n'y a
que deux solutions : ou on conserve un état côté serveur et on compte
sur la bonne volonté de l'utilisateur (on l'appâte avec un service en
plus par exemple) pour se faire reconnaître par son login+pass, ou alors
on conserve la trace côté client (cookie). Il n'y a pas d'autres
solutions. Dans les solutions côté client, on peut avoir une application
java ou autre (php-gtk, tiens par exemple !) qui va essayer de pourrir
la base de registres ou autre, mais il faudra bien stocker l'information
sur la machine locale.
Il pourrait y avoir intérêt en particulier ( c'est mon cas ), si ce
login/password l'identifierait comme ayant déjà passé un certain
temps/nombre de fois sur la partie protégée de mon site, après quoi il
devrait payer pour continuer ses visites.
Oui. Si le but est de faire du preview gratuit limité dans le temps, on
ne peut compter que sur une validation manuelle des demandes de preview
pour essayer de détecter les "fraudeurs", et une limitation des
prestations pour encourager l'upgrade. Par exemple, ne donner les stats
que sur 1 mois et non 6 mois.
Donc, en conclusion, je pense ( détrompez-moi si j'ai faux ), que la
seule solution, pour identifier un visiteur ayant intérêt à paraître
comme nouveau visiteur, serait de l'identifier ( de manière sûre de
préférence ), d'après ses données de connexion...
Si on pouvait, oui, mais comment ferez vous pour m'identifier alors que
je suis, dans une même semaine, chez 5 ou 6 clients différents ? Passé
un temps, et cela avait fait un tollé général, INTEL avait voulu
embarquer des identifiants uniques dans chaque µp... Cela aurait été un
début de solution (début hein, parce que comme on peut envoyer n'importe
quoi au serveur dès lors que ça vient du client...)
...Et là, problème: L'adresse ip ne suffit pas, car elle peut être
commune à plusieurs visiteurs différents à des moments différents, et
elle peut changer pour le même visiteur, suivant le moment...
Et même pire que ça, vous ne pouvez pas la connaître avec certitude de
toutes façons.
Monsieur John Gallet dirait ( Il me semble qu'il l'a déjà dit ),
qu'il est totalement impossible d'identifier un visiteur par son adresse
ip, ni par un autre moyen si le visiteur ne le souhaite pas précisément.
Il l'a dit (et il le répète, vous pouvez laisser tomber le "monsieur"
;-)..). Quelqu'un qui a intérêt à truander y arrivera toujours dans ce
contexte.
Dont acte: Je suis mal barré.
il faut transformer la motivation de l'internaute pour qu'il ait intérêt
à conserver son identification et non intérêt à la perdre.
Conclusion: Je ne peux pas offrir une "période d'essai" à mes
visiteurs c'est comme ça et pas autrement.
Si, mais sur des fonctionnalités restreintes pour encourager l'upgrade.
Avec une limitation dans le temps de cette période et une validation
manuelle des demandes. Ca forcera au moins le "petit malin" à ouvrir une
autre boite email et être créatif (on joue sur la lassitude dudit malin,
c'est tout). Enfin la nouvelle boite mail, il suffit d'un UNIQUE bien
placé en sgbd, pas besoin de la validation manuelle pour ça.
Et... Pour les Adsense, comme procède Google, pour identifier les
visiteurs ayant cliqués, qui sont précidément, le propriétaire des
Adsense de son site ?
C'est truandable, mais là aussi il faut voir les enjeux.
- Cà marche parce que le nom de la variable de session est connu, et sa valeur assure l'authentification.
On va avoir du mal à faire autrement. Si on veut récupérer "quelque chose" côté serveur, il faut bien qu'on sache *où* on va le récupérer. Que ce soit dans $_REQUEST['id_session'], dans $PHP_SESSION_ID, dans $_COOKIES['pouetpouet'], peu importe, mais il faut bien qu'on sache où on va le récupérer.
l'identificateur de session devait être crypté, comment faire pour sélectionner le bon couple login/password à partir de la database, pour comparer la valeur cryptée du login, à celle de la variable de session ?
L'id_session contient n'importe quoi du moment que c'est impossible à deviner de l'extérieur par un attaquant. Il n'est pas nécessairement bon d'y inclure le login, chiffré ou non. Cf le chapitre sur les sessions (le chap. 10 je crois) du cours que je diffuse sur www.saphirtech.fr pour plus de détails sur une implémentation manuelle possible (et comprendre les principes même si on utilise ensuite les sessions natives).
- Cà marche, si et seulement si le visiteur a déjà un login/password, mais rien ne l'empêche ( s'il y a intérêt ), de faire semblant de ne pas avoir de login, et à redemander ( ou fournir ) un nouveau couple login/password. Tout à fait. En fait il y a deux problème bien distincts :
1) au cours d'une "même session" (on va dire pour simplifier : un intervalle de 10 minutes) savoir que la même souris a cliqué sur X pages. Pour ceci, les sessions sont une (bonne) solution. Que ce soit les sessions natives PHP ou autre d'ailleurs.
2) complètement autre problème : sachant qu'un clic de souris a été généré, est-ce que c'est la même souris que la semaine dernière (je suppose ici une utilisation poste mono-utilisateur) ? Là dessus il n'y a que deux solutions : ou on conserve un état côté serveur et on compte sur la bonne volonté de l'utilisateur (on l'appâte avec un service en plus par exemple) pour se faire reconnaître par son login+pass, ou alors on conserve la trace côté client (cookie). Il n'y a pas d'autres solutions. Dans les solutions côté client, on peut avoir une application java ou autre (php-gtk, tiens par exemple !) qui va essayer de pourrir la base de registres ou autre, mais il faudra bien stocker l'information sur la machine locale.
Il pourrait y avoir intérêt en particulier ( c'est mon cas ), si ce login/password l'identifierait comme ayant déjà passé un certain temps/nombre de fois sur la partie protégée de mon site, après quoi il devrait payer pour continuer ses visites. Oui. Si le but est de faire du preview gratuit limité dans le temps, on
ne peut compter que sur une validation manuelle des demandes de preview pour essayer de détecter les "fraudeurs", et une limitation des prestations pour encourager l'upgrade. Par exemple, ne donner les stats que sur 1 mois et non 6 mois.
Donc, en conclusion, je pense ( détrompez-moi si j'ai faux ), que la seule solution, pour identifier un visiteur ayant intérêt à paraître comme nouveau visiteur, serait de l'identifier ( de manière sûre de préférence ), d'après ses données de connexion...
Si on pouvait, oui, mais comment ferez vous pour m'identifier alors que je suis, dans une même semaine, chez 5 ou 6 clients différents ? Passé un temps, et cela avait fait un tollé général, INTEL avait voulu embarquer des identifiants uniques dans chaque µp... Cela aurait été un début de solution (début hein, parce que comme on peut envoyer n'importe quoi au serveur dès lors que ça vient du client...)
...Et là, problème: L'adresse ip ne suffit pas, car elle peut être commune à plusieurs visiteurs différents à des moments différents, et elle peut changer pour le même visiteur, suivant le moment... Et même pire que ça, vous ne pouvez pas la connaître avec certitude de
toutes façons.
Monsieur John Gallet dirait ( Il me semble qu'il l'a déjà dit ), qu'il est totalement impossible d'identifier un visiteur par son adresse ip, ni par un autre moyen si le visiteur ne le souhaite pas précisément. Il l'a dit (et il le répète, vous pouvez laisser tomber le "monsieur"
;-)..). Quelqu'un qui a intérêt à truander y arrivera toujours dans ce contexte.
Dont acte: Je suis mal barré. il faut transformer la motivation de l'internaute pour qu'il ait intérêt
à conserver son identification et non intérêt à la perdre.
Conclusion: Je ne peux pas offrir une "période d'essai" à mes visiteurs c'est comme ça et pas autrement. Si, mais sur des fonctionnalités restreintes pour encourager l'upgrade.
Avec une limitation dans le temps de cette période et une validation manuelle des demandes. Ca forcera au moins le "petit malin" à ouvrir une autre boite email et être créatif (on joue sur la lassitude dudit malin, c'est tout). Enfin la nouvelle boite mail, il suffit d'un UNIQUE bien placé en sgbd, pas besoin de la validation manuelle pour ça.
Et... Pour les Adsense, comme procède Google, pour identifier les visiteurs ayant cliqués, qui sont précidément, le propriétaire des Adsense de son site ?
C'est truandable, mais là aussi il faut voir les enjeux.
a++; JG
Jean-Francois Ortolo
Bonjour Monsieur ( Je suis incorrigible ;) :( )
Finalement compte tenu des caractéristiques de mon site, je ne pense pas qu'il soit intéressant pour moi, de limiter les fonctionnalités gratuites de mon site, car celà influe directement sur la validité de mes stats, et partant, sur la propension qu'auraient les visiteurs, à s'abonner. D'autres formes de limitations ( avec ou sans pronostics tout faits ) sont envisageables mais me semblent d'une efficacité douteuse.
Donc, compte tenu des éléments en présence, il me semble seulement faisable, de m'en remettre au soft fourni par la firme intermédiaire de paiement ( Billing France à première vue ), et de demander aux visiteurs de s'abonner immédiatement, sans période d'essai gratuite.
Il se trouve que la fraction de visiteurs nouveaux/par moteur de recherche est tombé à la portion congrue, par rapport à mes fidèles, moins de 10% de l'ensemble représentant quand même de 600 à 700 visites/jours, dixit mes statistiques Urchin. Bof, on sait ce que ça vaut, Urchin... :(
Enfin... Voilà une digne conclusion à un problème bien posé. Pfffooouuu...
Merci beaucoup de vos conseils.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
Bonjour Monsieur ( Je suis incorrigible ;) :( )
Finalement compte tenu des caractéristiques de mon site, je ne pense
pas qu'il soit intéressant pour moi, de limiter les fonctionnalités
gratuites de mon site, car celà influe directement sur la validité de
mes stats, et partant, sur la propension qu'auraient les visiteurs, à
s'abonner. D'autres formes de limitations ( avec ou sans pronostics tout
faits ) sont envisageables mais me semblent d'une efficacité douteuse.
Donc, compte tenu des éléments en présence, il me semble seulement
faisable, de m'en remettre au soft fourni par la firme intermédiaire de
paiement ( Billing France à première vue ), et de demander aux
visiteurs de s'abonner immédiatement, sans période d'essai gratuite.
Il se trouve que la fraction de visiteurs nouveaux/par moteur de
recherche est tombé à la portion congrue, par rapport à mes fidèles,
moins de 10% de l'ensemble représentant quand même de 600 à 700
visites/jours, dixit mes statistiques Urchin. Bof, on sait ce que ça
vaut, Urchin... :(
Enfin... Voilà une digne conclusion à un problème bien posé.
Pfffooouuu...
Merci beaucoup de vos conseils.
Jean-François Ortolo
--
Visitez mon site gratuit donnant des Statistiques
et des Historiques Graphiques sur les Courses de Chevaux:
http://www.ortolojf-courses.com
Finalement compte tenu des caractéristiques de mon site, je ne pense pas qu'il soit intéressant pour moi, de limiter les fonctionnalités gratuites de mon site, car celà influe directement sur la validité de mes stats, et partant, sur la propension qu'auraient les visiteurs, à s'abonner. D'autres formes de limitations ( avec ou sans pronostics tout faits ) sont envisageables mais me semblent d'une efficacité douteuse.
Donc, compte tenu des éléments en présence, il me semble seulement faisable, de m'en remettre au soft fourni par la firme intermédiaire de paiement ( Billing France à première vue ), et de demander aux visiteurs de s'abonner immédiatement, sans période d'essai gratuite.
Il se trouve que la fraction de visiteurs nouveaux/par moteur de recherche est tombé à la portion congrue, par rapport à mes fidèles, moins de 10% de l'ensemble représentant quand même de 600 à 700 visites/jours, dixit mes statistiques Urchin. Bof, on sait ce que ça vaut, Urchin... :(
Enfin... Voilà une digne conclusion à un problème bien posé. Pfffooouuu...
Merci beaucoup de vos conseils.
Jean-François Ortolo
-- Visitez mon site gratuit donnant des Statistiques et des Historiques Graphiques sur les Courses de Chevaux: http://www.ortolojf-courses.com
