HTTP_REFERER

[adn]

Hello,

Ptite question (j'ai pas testé ) $_SERVER["HTTP_REFERER"] renvoie-t-il l'url précédente même quand le lien précédent à déclencher l'ouverture d'une nouvelle fenêtre (avec target="_blank") ?

Merci

[Dan]

Oui, sauf si le client qui visitait l'URL précédente bloque les HTTP_REFERER.

Cela arrive avec des proxies ou firewalls... mais n'est pas lié au "target=_blank"

[adn]

Trop rapide Dan, merci.

Je pose cette question car une plateforme d'affiliation (encore en cours de dev.) que je souhaite intégrer gère la provenance par HTTP_REFERER et non par un argument. Cela me surprenait car jusqu'à maintenant j'ai toujours vu un argument dans le lien pour le suivi de la source.

Donc si je te suis, des clients que je vais lui envoyer risquent de passer à la trappe

Peux-tu éventuellement m'en dire plus sur ton point que je bétonne mes arguments pour lui demander de changer de système ?

Merci

[Dan]

Certains firewalls, comme Norton ou Outpost, permettent de masquer le $_SERVER['HTTP_REFERER']. J'imagine que tous les firewalls sérieux offrent cette option mais je n'ai vérifié que ces deux là.

Donc en se basant sur le REFERER, on peut louper des hits, mais cela reste suffisamment peu utilisé. J'ai moins de 1 % de référants masqués sur le Hub.

Dan

[Jan]

Le taux d'internautes qui bloquent (ou fakent) les référants est en effet assez faible, mais ne serait-il pas plus fiable pour lui comme pour toi qu'il fournisse une URL de lien spécifique à chacun de ses affiliés? Par exemple une url avec une variable passée par get, du style:

-http://www.affilieur.com/?referant=adn pour toi

-http://www.affilieur.com/?referant=toto pour toto

etc...

Ensuite il n'a plus qu'à enregistrer la variable à l'arrivée sur sa page.

[adn]

OK, donc çà tiendrait la route mais pour être béton, vaudrait mieux un argument de plus dans le lien.

Encore merci

[Jeanluc]

Certains navigateurs permettent aussi de masquer le referrer, mais, comme le dit Dan, rares sont ceux qui le font.

Je pense que la plupart des systèmes d'affiliation utilisent le referrer pour vérifier la validité des clics. Chez TradeDoubler, par exemple, ils rejettent les clics venant d'une URL non approuvée, sauf si le clic conduit à une commande.

Jean-Luc

[adn]

Mais qu'est-ce qui l'emporte, la présence de l'argument dans l'url ou la validité d'un referrer ?

Dois-je refuser un système sur referrer ? Pour le moment, je peux encore intervenir sur leur solution, je pense.

[Jan]

Mais qu'est-ce qui l'emporte, la présence de l'argument dans l'url ou la validité d'un referrer ?

<{POST_SNAPBACK}>

L'un n'empêche pas l'autre. Ton affilieur peut très bien accèder aux 2 informations. Mais l'argument dans l'url me semble plus fiable, même si la taux d'erreurs en ne prenant en compte que le referer sera très faible.

[Anonymus]

le problème qui peut se poser, avec ta solution est celui-ci :

Un moteur récupère l'url, et la stocke.

Il va ensuite (qques heure, ou quelques jours après) visiter cette url, avec les arguments.

Cela doit il déclencher un 'hit' chez la plateforme ?

Non.

La plateforme a rencontré des problèmes similaires, et c'est pour ca qu'ils utilisent le referer.

Lorsqu'un outil bloque le referer, en général, il ne l'écrase pas, il le modifie. Si tu stockes l'info, tu n'auras pas :

- pas de referer

mais

- referer = ___________

Donc, tu sais qu'il y a un referer, bien que tu ne saches pas lequel c'est.

La solution serait peut être de combiner les 2 méthodes :

- referer actif (quelqu'il soit)

- argument valide, qui t'identifie.

Anonymus.