Je termine ma formation php avec les cookies . questions diverses .

Zecat · 26 Septembre 2010

Voila, le dernier chapitre de ma formation php est en cours et j'aurais quelques questions pour férus de cookies ...

Le contexte :
===========
En init session de chaque page du site, je lit le cookie nommé "moncookie".
si absent : je le pose avec un contenu unique (basé sur microtime+une babiole). Donc un truc unique de chez unique.
si présent : je lit le contenu sans le changer.

Et donc je me retrouve avec une variable $num_machine qui contient cet identifiant de la becanne du visiteur.

Le probleme
==========
Certains visiteurs ne semblent pas accepter les cookies et du coup ca me retourne un numero de becanne différent à chaque page ... logique.

Questions :
1 - quelle est à peu près la proportion de visiteur refusant les cookies ?
2 - Comment contournez vous ce type de cas ?
3 - Est ce que ca se fait d'imposer au visiteur d'accepter les cookies sinon pas d'accès au site ?
4 - Ce refus des cookies peut il être une alerte disant "suspicion de spider" ou pas vraiment vu le 1/?

loran750 · 26 Septembre 2010

1- quasi 100% pour un cookie en provenance du site même (source : http://www.grc.com/cookies/stats.htm)
2- m'en fiche, j'utilise le système de reconnaissance soit de mon CMS soit de via la brique applicative de mon framework. Je réinvente pas la roue

Sinon l'aternative est d'utiliser la session du navigateur comme identifiant de connexion.
3- Dommage que ton site soit lié à l'utilisation de cookie. Qu'a-t-il de si spécifique ?
4- les spiders reproduisent les entêtes, les agents, ... des navigateurs.

Zecat · 26 Septembre 2010

loran750 a dit:
Sinon l'aternative est d'utiliser la session du navigateur comme identifiant de connexion.]

J'utilise déjà le niveau session mais c'est un identifiant de connexion comme tu le dit. la je cherche a remonter d'un cran avec un indentifiant de machine.

loran750 a dit:
3- Dommage que ton site soit lié à l'utilisation de cookie. Qu'a-t-il de si spécifique ?

Non non il n'est pas lié a l'utilisation de cookie. Je fais juste un test pour voir ce que les cookies permettent ainsi que leurs limites ... qui semblent vite atteinte :roll:

Zecat · 26 Septembre 2010

loran750 a dit:
1- quasi 100% pour un cookie en provenance du site même (source : http://www.grc.com/cookies/stats.htm)

Heu t'es sur qu'on parle de la meme chose ? parce que mes premiers constats sont inverses : une majorité les acceptent et ca coince que sur quelques uns ...

On parle bien de

Code:

setcookie('lenom', $lecontenu, time() + 365*24*3600, null, null, false, true);

:?:

Parce que moi dans 90 % des cas, je recupère derriere un $_COOKIE['lenom'] correctement rempli :roll:

loran750 · 26 Septembre 2010

On parle de la même chose. le 100% c'est le taux d'acceptation pour un certain type de cookies. Il tombe à 87% pour des cookies externes ou "3rd Party" (je te laisse chercher la différence). Regarde le site internet.

Zecat · 26 Septembre 2010

loran750 a dit:
On parle de la même chose. le 100% c'est le taux d'acceptation pour un certain type de cookies. Il tombe à 87% pour des cookies externes ou "3rd Party" (je te laisse chercher la différence). Regarde le site internet.

Arf ... ma question etait le taux REFUSANT ... !!! et ta réponse 100 % était manifestement le taux ACCEPTANT :roll:

jcaron · 26 Septembre 2010

Oui, de nos jours, si tout est fait correctement, l'immense majorité des utilisateurs/navigateurs acceptent les cookies (ne serait-ce que parce que sans cookies, il y a des tonnes de sites qui sont inutilisables).

Donc 90% seulement c'est le signe qu'il y a un problème. Par exemple:
- tu n'indiques pas de path: si la première page visitée est /toto/machin, alors /bidule/truc ne verra pas le cookie (et /chose non plus)
- même chose au niveau domaine si tu utilises des sous-domaines différents
- tu utilises des frames, et tu fais le setcookie dans les frames plutôt que le frameset (ou la page contenante pour un iframe). Résultat, les différents frames étant chargés (au moins potentiellement/partiellement) en parallèle, chacun a droit à un cookie différent

Evidemment, la plupart des robots type crawler de moteur de recherche n'acceptent pas les cookies, mais ceux qui veulent se faire passer pour de vrais utilisateurs le feront souvent.

Note que la "session" php peut très bien être paramétrée pour durer nettement plus qu'une session du navigateur (tu peux régler les paramètres du cookie de session exactement comme n'importe quel cookie).

Aussi, si tu utilises Analytics, il se charge de mettre tout un tas de cookies pour toi, tu peux les récupérer et éviter de dupliquer le boulot (et en plus c'est le signe que le client "comprend" le JS).

Jacques.

Zecat · 26 Septembre 2010

jcaron a dit:
Oui, de nos jours, si tout est fait correctement, l'immense majorité des utilisateurs/navigateurs acceptent les cookies (ne serait-ce que parce que sans cookies, il y a des tonnes de sites qui sont inutilisables).

Donc 90% seulement c'est le signe qu'il y a un problème. Par exemple:
- tu n'indiques pas de path: si la première page visitée est /toto/machin, alors /bidule/truc ne verra pas le cookie (et /chose non plus)
- même chose au niveau domaine si tu utilises des sous-domaines différents
- tu utilises des frames, et tu fais le setcookie dans les frames plutôt que le frameset (ou la page contenante pour un iframe). Résultat, les différents frames étant chargés (au moins potentiellement/partiellement) en parallèle, chacun a droit à un cookie différent.

Bon ca va sur ces points je suis clean. Toutes pages à la racine, pas de sous domaine, et pas de frame. En fait j'ai dit 90 % au pif au ressenti mais en fait ca semble bien 100 % ... j'avais juste un bug de parsing d'une chaine qui m'a "enduit d'erreur" :wink:

jcaron a dit:
Evidemment, la plupart des robots type crawler de moteur de recherche n'acceptent pas les cookies, mais ceux qui veulent se faire passer pour de vrais utilisateurs le feront souvent.

Noté ...

jcaron a dit:
Note que la "session" php peut très bien être paramétrée pour durer nettement plus qu'une session du navigateur (tu peux régler les paramètres du cookie de session exactement comme n'importe quel cookie).

Plus longtemps c'est quoi ? quelle est la limite raisonable ? et comment on fait ca ?

jcaron a dit:
Aussi, si tu utilises Analytics, il se charge de mettre tout un tas de cookies pour toi, tu peux les récupérer et éviter de dupliquer le boulot (et en plus c'est le signe que le client "comprend" le JS).

arf effectivement y a des trucs a aller fouiner ... je vais fouiner et voir si dans les cookie analytics je trouve mon bonheur ...

question : un client qui pije pas js c'est forcément un spider ?

Zecat · 26 Septembre 2010

jcaron a dit:
Aussi, si tu utilises Analytics, il se charge de mettre tout un tas de cookies pour toi, tu peux les récupérer et éviter de dupliquer le boulot (et en plus c'est le signe que le client "comprend" le JS).

1 - Je dois pas avoir les yeux en face des trous mais je trouve aucun cookie analytics (des google en pagaille mais rien sur analytics). tu peux m'aiguiller sur la bonne piste ?

2 - Je suppose que comme pour MES cookies, ceux de analytics ne sont visibles qu'au rechargement d'une page ? Et donc en cas de premiere visite y aura rien ? (et comme en plus mon code analytics est en fin de page ...).

jcaron · 26 Septembre 2010

Pour le cookie de session, ça se passe dans session_set_cookie_params, qui prend des paramètres très similaires à ceux de setcookie. Tu peux aussi le faire dans php.ini. Pour la durée, c'est toi qui vois en fonction de tes besoins.

Les cookies GA sont les fameux __utma, __utmb, __utmc et __utmz, une petite recherche devrait te dire assez rapidement lequel fait quoi.

Les cookies seront créés lors de l'appel du tag Analytics (l'image qui est chargée plutôt que le script il me semble), donc tu les auras lors de la page suivante. Evidemment l'inconvénient par rapport à les mettre toi-même, c'est qu'il peut y avoir des cas de figure où la page n'aura pas été entièrement chargée par exemple, et où les cookies GA ne seront pas mis en place.

Un client qui pige le JS (en dehors des trucs super-top-classiques que même Google arrive à repérer) c'est presque forcément un vrai utilisateur, à moins que quelqu'un s'amuse à "télécommander" un browser (c'est tout à fait possible, mais je pense que c'est plutôt rare, je peux me tromper). Un client qui ne pige pas le JS ça a de fortes chances de ne pas en être un, mais il y a toujours des cas particuliers: quelques-uns désactivent le JS, ton JS peut être bloqué par un firewall ou anti-virus qui fait du zèle, ton JS peut planter et ne pas produire le résultat escompté... Mais à part le dernier, ça doit être à peu près du même niveau que le blocage des cookies.

Jacques.

Zecat · 26 Septembre 2010

Tout est clair ... merci jacques.

Bon je vais adopter le compromis suivant :

1 - je gere moi meme mes petits gateaux
2 - je vais en parralèlle lire ce que me dit analytics pour info complémentaire ...

Zecat · 26 Septembre 2010

jcaron a dit:
Les cookies GA sont les fameux __utma, __utmb, __utmc et __utmz, une petite recherche devrait te dire assez rapidement lequel fait quoi.

Heu rapidement rapidement ... faut voir :mrgreen:

le print-r($_COOKIE) me retourne ca :

Array (
[visitornum] => NNNNNNNN
[PHPSESSID] => NNNNNNNNNNNNNNNNNNN
[__utma] => 19**19***.689493***.1284625***.1285517***.1285525***.**
[__utmz] => 19**19***.1285429***.80.7.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=longislandivf.com [__utmb] => 19**19***.8.10.1285525***
[__utmc] => 19**19*** )

J'ai masque avec des *** ne sachant pas trop ce que c'est ... bref je pige pas du tout ce que c'est (les deux premiers ca va lol)!
En plus c'ets quoi ce longislandivf.com ? c'est rien de connu chez moi ...

EDIT : c'est good j'ai trouvé 'google est mon ami ...)

Zecat · 26 Septembre 2010

Je reviens vers toi jacques because un truc me titille ...

Voila apres decodage et mise au clair ce que me retourne utma sur ma machine :

site:nnnnnnnnnn
visitor:68***3131
first:2010/09/16 - 04:32:27
last:2010/09/26 - 14:16:44
en cours:2010/09/26 - 16:22:16
total vis:90

Sauf que ma premiere visite sur mon site c'est pas le 16/09 ... :roll: (j'y vais tous les jours depuis son lancement le 1er juillet) !

DEu coup j'ai une grosse interrogation aussi sur l'identifiant de l'internaute ... c'est un truc unique mais unqiue depuis quand ? en gros est ce que le meme internaute va avoir au fil des periodes analytics plusieurs identifiants "uniques" ?

JanoLapin · 26 Septembre 2010

les cookies de GG ne sont valables que 30 jours, je crois...

par ailleurs peut-être as-tu vidé ton cache et ets cookies juste avant la date du first ?

loran750 · 27 Septembre 2010

Les cookies de Google Search, c'est 180 jours max.
Le cookie de 30 jours, c'est celui d'Adwords/Adsense.
Cependant les cookies sont conservés sur le serveur 18 mois, les @ IP 9 mois
Cf. https://www.google.com/intl/fr/privacy_cookies.html
https://www.google.com/support/accounts/bin/answer.py?hl=fr&answer=54041
https://www.google.com/privacy_faq.html#toc-terms-cookie

Zecat · 27 Septembre 2010

JanoLapin a dit:
par ailleurs peut-être as-tu vidé ton cache et ets cookies juste avant la date du first ?

Non pas le souvenir et comme le 16 c'est il y a peine 10jours je m'en souviendrais ...

jcaron · 27 Septembre 2010

Je suppose que tu as Analytics depuis le départ? Sinon forcément les cookies ne peuvent dater que du moment où tu as mis Analytics...

Ensuite, oui, effacement des cookies, changement de machine ou de navigateur... Normalement utma est conservé pendant 2 ans, mais tu peux le modifier avec _setVisitorCookieTimeout()

Jacques.

Zecat · 27 Septembre 2010

jcaron a dit:
Je suppose que tu as Analytics depuis le départ? Sinon forcément les cookies ne peuvent dater que du moment où tu as mis Analytics...

Ensuite, oui, effacement des cookies, changement de machine ou de navigateur... Normalement utma est conservé pendant 2 ans, mais tu peux le modifier avec _setVisitorCookieTimeout()

Jacques.

Oui ga depuis le depart ...

par contre j'alterne mes visites sur le site entre IE et FF ... tu sembles dire que ca a un impact sur utma sur ma machine ?

jcaron · 27 Septembre 2010

Tous les cookies sont spécifiques à un navigateur donné, FF, IE, Opera, Safari, etc. ont chacun les leurs.

Jacques.

Zecat · 27 Septembre 2010

Bon ben y a pas a dire wri pour se former a la vitesse grand V y a pas mieux :wink: Merci jacques de ton aide en private ... pertinente comme toujours ...

et donc au final je me range a l'avis initial de jacques (qui comme souvent a raison dès le depart :wink: ) et je ne réinvente pas la roue en profitant du taff deja fait par google et je ne pose aucun cookie moi meme :

$utma_tab=explode(".", $_COOKIE['__utma']);
$visitornum=$utma_tab[1];

et hop me voila avec un numero d'internaute assez fiable d'une part et une detection immediate des "vilains" qui refusent les cookies ...

Zecat · 27 Septembre 2010

jcaron a dit:
Tous les cookies sont spécifiques à un navigateur donné, FF, IE, Opera, Safari, etc. ont chacun les leurs.

Jacques.

C'est aussi vrai pour les cookies posés par google je presume et donc un meme internaute passant de IE a FF aura deux numero d'internaute différents ? Tiens je vais aller vérifier ...

Edit : effectivement : un numero d'internaute sous IE et un autre sous FF.

aladdin · 27 Septembre 2010

oui mais ca ce n'est pas vraiment un problème, l'utilisateur lambda utilise en général un seul navigateur, à part pour un problème technique sur un site ou pour un webdesigner qui veux vérifier la compatibilité de son propre site, c'est quand même rare qu'un utilisateur accède au même site à partir de deux navigateur différent juste parce que ca l'amuse

Zecat · 27 Septembre 2010

aladdin a dit:
oui mais ca ce n'est pas vraiment un problème, l'utilisateur lambda utilise en général un seul navigateur, à part pour un problème technique sur un site ou pour un webdesigner qui veux vérifier la compatibilité de son propre site, c'est quand même rare qu'un utilisateur accède au même site à partir de deux navigateur différent juste parce que ca l'amuse

Oui tout a fait et puis il y a aussi le cas de deux machines sur la meme ip ... donc impossible de dissocier les deux cas ...

L'essentiel est que avec le utma on voit de suite :

1 - si c'est un visiteur "stable" (même si il pourra changer de num internaute)
2 - si c'ets un visiteur qui accepte le JS et les cookies de google ... (si non alors suspect de chez suspect).

et tout ca en deux lignes de code : Merci Google analytics :mrgreen:

Ensuite un petit log qui mémorise : date heure, ip, numinternaute, pagevue, origine visite (serp, ref, etc) et on a deja un tracking assez solide et les moyens de virer une bonne partie des spiders non autorisés ...

avec en complément :
- une surveillance du nb de pages par ip et periode de temps (s et minute)
- quelques liens cachés "pieges" à spider (non présentés aux bots identifiés et autorisés)

et ca rase la mauvaise herbe plutot court :mrgreen: :mrgreen:

aladdin · 27 Septembre 2010

et juste par curiosité, tu comptes faire quoi avec ton script ?

Zecat · 27 Septembre 2010

aladdin a dit:
et juste par curiosité, tu comptes faire quoi avec ton script ?

Ca participe a un systeme global anti spider sur un site de plusieurs millions de pages et ou je veux limiter les aspi au maximum ... enfin au minimum ...

1 - j'en avais besoin
2 - c'est impec comme sujet d'apprentissage intensif du php (ca fait travailler tous les muscles :mrgreen: )