Session et Cookies

galerie-net.com · 14 Décembre 2003

J'ai cru comprendre que les sessions ne sont pas des choses à utiliser...

Comment remplace t'on des sessions par des cookies ?

anguenot.com · 14 Décembre 2003

Tout dépend de ce que tu veux faire. Un accès à certaines zones de ton site par cookie n'est pas non plus forcément souhaitable en terme de référencement.

Peux-tu préciser :?:

binarythinking · 14 Décembre 2003

Salut,

En effet, les sessions ajoutent des SESSION ID à la fin de tes urls lorsque le visiteur n'accepte pas les cookies de sessions (google par ex)

ton lien : "index.php?page=news" devient "index.php?page=news&SID=1564387384413131"

Et les moteurs ne suivent pas ces liens...

Tu as plusieurs solutions :

1 - N'activer les sessions dans les parties de ton site que lorsque cela est vraiment nécessaire...

2 - Si tu as besoin, comme moi sur mon site, d'activer les sessions tt le temps, il te suffit de vérifier que ce n'est pas un moteur avant d'activer les sessions sur ta page...

Voici le code PHP que j'ai chez moi :wink: :

Code:

/* Si le visiteur est un crawlers d'un moteur de recherche, on désactive les sessions pour qu'il puisse naviguer sur toutes les pages et on envoie un mail */

if(
	(!ereg('216.239.46.',$_SERVER['REMOTE_ADDR'])) 		/* 	GoogleBot 	*/
	AND 
	(!ereg('64.68.8',$_SERVER['REMOTE_ADDR']))			/* 	GoogleBot 	*/	
	AND 
	(!ereg('212.27.33.',$_SERVER['REMOTE_ADDR']))		/* 	Pompos Dir 	*/
	AND
	(!ereg('66.77.73.',$_SERVER['REMOTE_ADDR']))		/* 	FastSearch 	*/
	AND 
	(!ereg('66.28.250.',$_SERVER['REMOTE_ADDR']))		/* 	Alexa 		*/
	AND
	(!ereg('209.237.238.',$_SERVER['REMOTE_ADDR'])) 	/* 	Alexa	 	*/
	AND 
	(!ereg('204.123.28.',$_SERVER['REMOTE_ADDR']))		/* 	Mercator 	*/	
	AND 
	(!ereg('216.35.116.',$_SERVER['REMOTE_ADDR']))		/* 	Inktomi 	*/
	AND
	(!ereg('66.237.60.',$_SERVER['REMOTE_ADDR']))		/* 	OpenFind 	*/
	AND 
	(!ereg('64.152.75.114',$_SERVER['REMOTE_ADDR']))	/* 	Astalavista	*/
	AND 
	(!ereg('209.73.162.54',$_SERVER['REMOTE_ADDR']))	/* 	Astalavista */
	AND 
	(!ereg('216.39.48.',$_SERVER['REMOTE_ADDR']))		/* 	Astalavista */
	AND
	(!ereg('64.140.48.30',$_SERVER['REMOTE_ADDR'])) 	/* 	SlySearch 	*/
	AND 
	(!ereg('66.147.154.3',$_SERVER['REMOTE_ADDR']))		/* 	Almaden 	*/	
	AND 
	(!ereg('65.214.36.150',$_SERVER['REMOTE_ADDR']))	/* 	AskJeeves 	*/
	AND
	(!ereg('64.68.84.',$_SERVER['REMOTE_ADDR']))		/* 	GoogleImage	*/
	AND 
	(!ereg('195.101.94.209',$_SERVER['REMOTE_ADDR']))	/* 	Voila		*/
	AND
	(!ereg('209.249.66',$_SERVER['REMOTE_ADDR']))		/* 	WiseNut		*/
	AND 
	(!ereg('209.249.67',$_SERVER['REMOTE_ADDR']))		/* 	WiseNut		*/		
	AND
	(!ereg('195.154.174',$_SERVER['REMOTE_ADDR']))		/* 	Exabot		*/		
	AND
	(!ereg('66.196.',$_SERVER['REMOTE_ADDR']))			/* 	Inktomi		*/
	AND
	(!ereg('217.154.244',$_SERVER['REMOTE_ADDR']))		/* 	Migrabot	*/
	AND
	(!ereg('18.29.1.50',$_SERVER['REMOTE_ADDR']))		/* 	W3c	-XHTML	*/
	AND
	(!ereg('216.88.158.',$_SERVER['REMOTE_ADDR']))		/*  Looksmart	*/
	AND
	(!ereg('161.111.200.',$_SERVER['REMOTE_ADDR']))		/*  Moteur ES	*/
	
  ){

	/* Ce n'est pas un crawler recensé, on démarre la session */
	session_start();

}

anguenot.com · 14 Décembre 2003

Limite cloaking ton affaire :wink:

binarythinking · 14 Décembre 2003

anguenot.com a dit:
Limite cloaking ton affaire :wink:

Ah tiens c'est vrai ! Je n'avais pas remarqué... :lol:

galerie-net.com · 14 Décembre 2003

J'aime bien ton truc ... bon d'accord, c'est un peu agressif comme méthode, mais s'il n'y a pas mieux, je vais faire ça...

Les sessions sont super importantes sur toutes les pages de mon site car c'est aussi une boutique en ligne. J'affiche donc un petit caddie si le visiteur a mis qq ch dedans... Pour ça, il doit être loggé... d'où la session...

Merci pour l'astuce... :wink:

binarythinking · 14 Décembre 2003

galerie-net.com a dit:
J'aime bien ton truc ... bon d'accord, c'est un peu agressif comme méthode, mais s'il n'y a pas mieux, je vais faire ça...

Merci, je ne dis pas qu'il n'y a pas mieux mais, au moins, cela a le mérite de fonctionner...

galerie-net.com a dit:
Les sessions sont super importantes sur toutes les pages de mon site car c'est aussi une boutique en ligne. J'affiche donc un petit caddie si le visiteur a mis qq ch dedans... Pour ça, il doit être loggé... d'où la session...

Merci pour l'astuce... :wink:

De rien, je pense que je vais bientôt revoir le code d'ailleurs... Pense aussi à mettre à jour les IP d'autres crawlers qui pourraient apparaître...

Pierre-Louis

galerie-net.com · 14 Décembre 2003

Comment font les boutique en ligne pour etre vus par les moteurs s'ils utilisent des sessions ?

binarythinking · 14 Décembre 2003

Cela dépend aussi des langages, et puis, ils ne font pas ça en amateurs non plus !

Ah, j'oubliais, ils passent aussi peut-être sur WRI...

galerie-net.com · 14 Décembre 2003

C'est quoi la différence entre un amateur qui passe bcp de temps dessus et un professionel ? :wink:

anguenot.com · 14 Décembre 2003

galerie-net.com a dit:
C'est quoi la différence entre un amateur qui passe bcp de temps dessus et un professionel ? :wink:

Si l'amateur arrive vraiment à faire un site de niveau professionnel (style fnac.com), la différence entre lui et le professionnel est... qu'il est un peu c** de ne pas en vivre

BadProcESs · 15 Décembre 2003

En passant comme ca, c'est bizarre cette histoire de session passé en paramètre en PHP, j'ai jamais compris ca... EN ASP par exemple, les Session c tout bétement du type Session("LE_NOM_DE_SESSION") et puis basta, ca ne rajoute rien dans l'url de la page... Bref je comprend pas là... (enfin c'est un peu hors sujet)

Suede · 15 Décembre 2003

BadProcESs a dit:
En passant comme ca, c'est bizarre cette histoire de session passé en paramètre en PHP, j'ai jamais compris ca... EN ASP par exemple, les Session c tout bétement du type Session("LE_NOM_DE_SESSION") et puis basta, ca ne rajoute rien dans l'url de la page... Bref je comprend pas là... (enfin c'est un peu hors sujet)

PArce qu'elles sont passées par des cookies. Mais si les cookies ne sont pas acceptés, il faut passer par l'url.

François

Suede · 15 Décembre 2003

anguenot.com a dit:
Limite cloaking ton affaire :wink:

Pas du tout. Ca ne change pas le contenu de la page, ca permet juste aux moteurs de voir ce qu'ils verraient s'il acceptaient les sessions/cookies.
Il y avait eu des discussions sur cela à propos entre autres des sessions de PHPBB avec entre autre la participitation de Googleguy.

François

BadProcESs · 15 Décembre 2003

Suede a dit:
BadProcESs a dit:

En passant comme ca, c'est bizarre cette histoire de session passé en paramètre en PHP, j'ai jamais compris ca... EN ASP par exemple, les Session c tout bétement du type Session("LE_NOM_DE_SESSION") et puis basta, ca ne rajoute rien dans l'url de la page... Bref je comprend pas là... (enfin c'est un peu hors sujet)

Cliquez pour agrandir...

PArce qu'elles sont passées par des cookies. Mais si les cookies ne sont pas acceptés, il faut passer par l'url.

François

C'est bizarre ca... En ASP, les variables de session n'ont besoin ni de cookie, ni de rien d'autre, tout se passe sur le serveur...

FightTheWar · 15 Décembre 2003

Bonjour,

Oui moi non plus je n'ai pas trouvé d'autre solution que de détecter s'il s'agit d'un robot avant de lancer la session.
Mais ce problème se pose surtout pour un hébergement mutualisé, pour ceux qui ont accès au php.ini il suffit de mettre :
session.use_only_cookies = 1
Il y a aussi la possibilité de modifier la valeur d'une variable du php.ini uniquement pour un script :
ini_set
Mais cette fonction est souvent bloquée par les hébergeurs

galerie-net.com > Je pense que les grosses boutiques rendent obligatoire l'utilisation des cookies pour prendre une commande et utilise session.use_only_cookies = 1, en tout cas c'est le cas de certaines.

galerie-net.com · 15 Décembre 2003

Ouais, mais je ne vais pas me retaper la programmation de mon site en ASP... :?

Donc si vous avez une réponse à ma question, ce serait cool de recentrer la discussion sur PHP les amis... :wink:

Suede · 15 Décembre 2003

BadProcESs a dit:
C'est bizarre ca... En ASP, les variables de session n'ont besoin ni de cookie, ni de rien d'autre, tout se passe sur le serveur...

Peut-etre, je ne connais pas trop ASP

Mais si c'est comme cela, il fait comment pour détecter les AOLiens qui changent d'IP toutes les 5 minutes?

François

galerie-net.com · 15 Décembre 2003

FightTheWar a dit:
Bonjour,

galerie-net.com > Je pense que les grosses boutiques rendent obligatoire l'utilisation des cookies pour prendre une commande et utilise session.use_only_cookies = 1, en tout cas c'est le cas de certaines.

Merci pour cette info... je vais me renseigner...

anguenot.com · 15 Décembre 2003

Suede a dit:
anguenot.com a dit:

Limite cloaking ton affaire :wink:

Cliquez pour agrandir...

Pas du tout. Ca ne change pas le contenu de la page, ca permet juste aux moteurs de voir ce qu'ils verraient s'il acceptaient les sessions/cookies.
Il y avait eu des discussions sur cela à propos entre autres des sessions de PHPBB avec entre autre la participitation de Googleguy.

François

D'accord avec toi, si c'est fait dans cet esprit, ça n'a pas lieu d'être sanctionné.
En revanche à partir du moment ou GG accepte ce "cloaking pour la bonne cause", il faut qu'ils oublient l'idée de sanctionner le "cloaking malhonnête" (que pourtant ils condamnent officiellement). Comment en effet peuvent-ils espérer faire la différence entre le "bon" et le "mauvais" cloaking... à part sur dénonciation.

BadProcESs · 15 Décembre 2003

Suede a dit:
BadProcESs a dit:

C'est bizarre ca... En ASP, les variables de session n'ont besoin ni de cookie, ni de rien d'autre, tout se passe sur le serveur...

Cliquez pour agrandir...

Peut-etre, je ne connais pas trop ASP
Mais si c'est comme cela, il fait comment pour détecter les AOLiens qui changent d'IP toutes les 5 minutes?

François

Je sais pas... A vrais dire, je ne me suis jamais vraiment posé la question... Faut dire que c'est stupide leurs système de changer d'ip toute les 5 minutes... Enfin bon, je m'arreterai là pour ce débas, car il n'a pas sa place dans ce thread effectivement...
Encore désolé pour l'initiateur de ce thread.

Suede · 15 Décembre 2003

anguenot.com a dit:
D'accord avec toi, si c'est fait dans cet esprit, ça n'a pas lieu d'être sanctionné.
En revanche à partir du moment ou GG accepte ce "cloaking pour la bonne cause", il faut qu'ils oublient l'idée de sanctionner le "cloaking malhonnête" (que pourtant ils condamnent officiellement). Comment en effet peuvent-ils espérer faire la différence entre le "bon" et le "mauvais" cloaking... à part sur dénonciation.

Pour détecter du cloaking, il faut qu'ils vérifient si version "google" <> version "normale".
Si supprimer les cookies pour google ne change rien, pas de pb.

François

snakeface · 15 Décembre 2003

Disons que le site utilise enable_trans_id = 0 ce qui force la "transmission" des sessions php par cookies :arrow: ... GGBot va t'il prendre la session (les cookies) ?????

:arrow: Le "start_session()" à chaque page va t'il perturber gg ? :arrow: Même si la page affiche tout le contenu sans utiliser de sessions. :?: :?:

C'est compréhensible ce que j'ecris? :?: 8O

cleden · 15 Décembre 2003

Bonjour tout le monde,

A ma connaissance ce n'est pas le session_start () qui perturbe google mais le SID dans l'URL.

Pour pallier à ce problème, on peut ne pas afficher ce dernier dans l'URL, il suffit, pour cela de modifier l'option du tran_sid soit activée. Chez certains hébergeurs, cette option est activée par défaut donc aucun problème de passage de bot. (c'est le cas d'OVH mutualisé).

Loïc.

galerie-net.com · 15 Décembre 2003

cleden a dit:
Bonjour tout le monde,

Chez certains hébergeurs, cette option est activée par défaut donc aucun problème de passage de bot. (c'est le cas d'OVH mutualisé).

Loïc.

Et pour les autres, on fait comment ?

snakeface · 15 Décembre 2003

Ici on parle de désactiver le phpsessid par url.

https://www.webrankinfo.com/forum/t/url-rewriting-et-sessions.5008/

Normalment ton hebergeur devrait accepter de paramétrer cette variable par .htaccess.

cleden · 15 Décembre 2003

Et pour les autres, on fait comment ?

Bonne question...

anguenot.com · 15 Décembre 2003

Suede a dit:
Pour détecter du cloaking, il faut qu'ils vérifient si version "google" <> version "normale".

Oui.
Pour faire ça de façon efficace à l'échelle de GG, il faut que ce soit fait par des robots.
Il faut donc que GG envoie des robots "anti-cloaking" dont le user-agent n'est plus "Googlebot etc..." et dont l'adresse IP n'est pas l'une des IP des GGbots connus.

Mais là, ils pénaliseront injustement le site de binarythinking: dilemme.

galerie-net.com · 15 Décembre 2003

Vous etes trop balaises pour moi à cette heure tardive...

binarythinking · 16 Décembre 2003

anguenot.com a dit:
Mais là, ils pénaliseront injustement le site de binarythinking: dilemme.

:cry:

Sinon pour en revenir à la discussion, je conseille quand même à tt ceux qui se posent la question de garder les sessions. Revenir en arrière vers les cookies serait une absurdité à mon sens.

De mon côté, comme j'ai la chance d'avoir mon propre serveur :lol: , je vais pouvoir modifier la config d'Apache grâce à vos conseils et éliminer les SID dans les url. Pour ceux qui n'ont pas cette opportunité, faites en sorte que votre site s'adapte aux bots afin que le fait de refuser les cookies ne les empêche pas de crawler votre site (ça présente aussi des avantages pour vous ! :wink: ). Tant que vous ne basculez pas du côté obscur de l'adaptabilité de votre site, c'est justifié !

Quant à la mini-discussion sur ASP, je tiens à préciser que les systèmes de sessions (PHP ou ASP) utilisent forcément des cookies en local chez le visiteur. Pour info, les sessions PHP ne sont, ni plus ni moins, qu'un système de cookies amélioré.

A+ Tout le monde et bon courage, Binary