Recherche avancée

Sur d’autres sites (10560)

• Cloaked Archive Wiki

  16 mai 2011, par Multimedia Mike — General

  Google’s Chrome browser has made me phenomenally lazy. I don’t even attempt to type proper, complete URLs into the address bar anymore. I just type something vaguely related to the address and let the search engine take over. I saw something weird when I used this method to visit Archive Team’s site :

  
  
  

  There’s greater detail when you elect to view more results from the site :

  
  
  

  As the administrator of a MediaWiki installation like the one that archiveteam.org runs on, I was a little worried that they might have a spam problem. However, clicking through to any of those out-of-place pages does not indicate anything related to pharmaceuticals. Viewing source also reveals nothing amiss.

  I quickly deduced that this is a textbook example of website cloaking. This is when a website reports different content to a search engine than it reports to normal web browsers (humans, presumably). General pseudocode :

  PLAIN TEXT

  C :

  1. if (web_request.user_agent_string == CRAWLER_USER_AGENT)
  2.  return cloaked_data ;
  3. else
  4.  return real_data ;

  You can verify this for yourself using the wget command line utility :

  <br />
$ wget --quiet --user-agent="<strong>Mozilla/5.0</strong>" \<br />
 http://www.archiveteam.org/index.php?title=Geocities -O - | grep \&lt;title\&gt;<br />
&lt;title&gt;GeoCities - Archiveteam&lt;/title&gt;

  $ wget —quiet —user-agent="Googlebot/2.1"
  http://www.archiveteam.org/index.php?title=Geocities -O - | grep \<title\>
  <title>Cheap xanax | Online Drug Store, Big Discounts</title>
  

  I guess the little web prank worked because the phaux-pharma stuff got indexed. It makes we wonder if there’s a MediaWiki plugin that does this automatically.

  For extra fun, here’s a site called the CloakingDetector which purports to be able to detect whether a page employs cloaking. This is just one humble observer’s opinion, but I don’t think the site works too well :
  
  

  
  
  

• Révision 20230 : genie/mail utilise notifications_envoyer_mails() plutot que directement envoyer_...

  4 mars 2013, par cedric -

  asynchrone

  detecte et gere automatiquement les mails HTML Seul impact : l’envoi de headers spécifiques doit se faire via #HTTP_HEADER dans le squelette du mail, et pas texte brut entre le sujet et le corps du mail. Ne concerne que d’éventuels mails de nouveautés personalisés avec des headers (...)

• Révision 20289 : Report de r20230 : genie/mail utilise notifications_envoyer_mails() plutot que d...

  12 mars 2013, par cedric -

  asynchrone

  detecte et gere automatiquement les mails HTML Seul impact : l’envoi de headers spécifiques doit se faire via #HTTP_HEADER dans le squelette du mail, et pas texte brut entre le sujet et le corps du mail. Ne concerne que d’éventuels mails de nouveautés personalisés avec des headers (...)