Маскировка Внешних Ссылок



  • Скрипт Link Cloaking
  • Маскировка продажных ссылок


  • Скрипт Link Cloaking

    Скрипт Link Cloaking

    Эта статья об одном из довольно распространенных способов маскировки внешних ссылок (по-английски – link cloaking).

    Работает link cloaking следующим образом. Просматривая страницу, посетитель видит обычную внутреннюю ссылку. Но, после перехода по ней – попадает на другой сайт.

    На сегодняшний день существует несколько способов создания таких ссылок. Но мы рассмотрим один из самых удачных (с моей точки зрения), не требующий поддержки со стороны браузера.

    Идея заключается в использовании редиректа и реализуется в два этапа:

    • 1) в корне сайта (папка, на которую указывает DOCUMENT_ROOT) создаем папку с именем pages.
    • 2) в этой папке размещаем три файла:
      • linkslist.php – в нем будет массив с внешними ссылками;
      • redirect.php – анализирует ссылку по которой был выполнен переход и отправляет посетителя на внешний ресурс;
      • .htaccess – передает все запросы скрипту redirect.php.

    Принцип работы

    На страницах сайта вы размещаете ссылки вида: http://site_name/pages/get/вторая_часть_адреса, где вторая_часть_адреса – может быть чем угодно, например, mypage.html или page1 и т.д. Тут все зависит от вашей фантазии.

    Преобразование адреса происходит следующим образом. При любом переходе по ссылке вида http://site_name/pages/get/......... к ней будут применены правила из .htaccess.

    Примечание. На сервере должен быть установлен и запущен apache mod_rewrite.

    С помощью правил в этом файле, мы заменяем в адресе get на redirect.php. Т.е. получится: http://site_name/pages/redirect.php/вторая_часть_адреса

    Скрипт redirect.php по второй части адрса выбирает внешнюю ссылку и отправляет браузеру redirect.

    Описанный порядок преобразования адресов изображен на диаграмме.

    порядок преобразования адресов

    Сам Скрипт

    linkslist.php
    <?php
    $linksList = array(
     'page1.html' => 'http://www.google.com',
     'page2.html' => 'http://www.php.net'
    );
    ?>

    Здесь объявлен обычный массив. Ключом элемента является вторая часть адреса внутренней ссылки, а значением – адрес внешнего ресурса.

    redirect.php
    <?php
    require_once('linkslist.php');
    $request = $_SERVER['REQUEST_URI'];
    $dest = explode('/', $request);
    $newUrlKey = end($dest);
    if (array_key_exists($newUrlKey, $linksList)) {
    header('Location:'.$linksList[$newUrlKey]);
    }
    else {
    header('Location:http://www.simplecoding.org');
    }
    ?>

    Здесь мы подключаем файл с массивом ссылок (строка 2). После этого выделяем из адреса вторую часть (строки 5, 6) и формируем заголовок с редиректом (строки 8-13).

    .htaccess
    <IfModule mod_rewrite.c>
    Options +FollowSymlinks
    RewriteEngine On
    RewriteRule ^get/(.+) /pages/redirect.php/$1 [L]
    </IfModule>

    В этом файле мы создали правило, которое меняет get на redirect.php в адресе.

    Заключение

    На сегодняшний день существует несколько готовых решений, которые выполняют эти же функции (например, плагины для WordPress вроде Hidden Affiliate Links).

    Самое главное, перед тем как использовать описанный в этой статье метод, вы должны четко понимать, что вам даст маскировка ссылок.

    Ведь, по большому, счету маскировка ссылок очень напоминает обман посетителя и поисковика. Или у вас другое мнение? Поетому предлагаю сперва оптимизировать сайт от большого ко-ва внешних ссылок.






    Как защитить свой сайт от детектирования в нём продажных ссылок типа Sape.com?

    Речь идёт не только о противодействии данному детектору продажных ссылок, но и любому другому. Работающему в виде отдельного ресурса, или встроенного в алгоритм поисковика :) Неважно.

    Давайте для примера не позволим определиться продажным ссылкам на сайтах, построенным на популярном движке LastoBlog,а заодно и на сплоговом движочке LastoSplog тоже.

    Сам скрипт:

    Как известно, стандартный код Сапы цепляется к сеттингам таким образом:

    global $mysape;
    define ('_SAPE_USER',"usersiteidentificator");
    require_once ("./data/sape/sape.php");
     $sape=new SAPE_client();
     $mysape=$sape->return_links();

    Предполагается, что папка сапы засунута внутрь файловой структуры движка, а не валяется беззащитно в его корне- отсюда и такой путь до файла с клиентским кодом, обратите внимание на сей аспект.

    Как и на то, что папка переименована в sape

    Теперь давайте допишем пару операторов- выделено красным:

    global $mysape;
    define ('_SAPE_USER',"usersiteidentificator");
    require_once ("./data/sape/sape.php");
    require_once ("./data/sape/sape_venality_name.php");
     $sape=new SAPE_client($sape_venality_name);
     $mysape=$sape->return_links();

    Ну и, естественно, в папочку сапы поместим ещё и такой код

    Имя файла, как понимаете, sape_venality_name.php)

    <?php

    $sape_venality_name=array();

    # Документы, работающие с глобалом GET:
    $allowed_pages=array("key.php","ping","remoute");

    # Разрешённые переменные в УРле иных документов:
    $allowed_var=array("");

    $tm=explode("?",$_SERVER['REQUEST_URI']);
    if (isset($tm[1]) and $tm[0]==str_replace($allowed_pages,"",$tm[0])) {
     $k=preg_match_all("/(.*)=(.*)\&/Uis",$tm[1]."&",$am);
     $bm=array();
     for ($i=0; $i < $k; $i++) {
      if ($am[2][$i]=="" or !in_array($am[1][$i],$allowed_var))continue;
      $bm[]=$am[1][$i]."=".$am[2][$i];
     }
     $tm[1]=implode("&",$bm);
     $sape_venality_name['request_uri']=
     $_SERVER['REQUEST_URI']=($tm[1]=="") ? $tm[0]: implode("?",$tm);
    }

    ?>

    После употребления этого кода (вызова его перед запуском класса Сапы) наш блог или сплог перестаёт реагировать на тестирование ресурса всякими Детекторами Продажных Ссылок на предмет наличия оных.

    Также, если к ресурсу подцеплены клиентские кода иных бирж по продаже ссылок, срабатывающие после клиентского кода сапы, то все проданные через такие биржи ссылочки также перестают определяться детектором (в большинстве случаев, а не стопроцентно, естественно).

    Тюнинг кода Сапы :)

    При внешнем управлении работой клиентского кода Сапы иногда требуется настроить кодировку, или ещё ряд каких моментов. Стандартно в этом случае следует сформировать массив с любым именем, создать в массиве нужные ключики, и присвоить им необходимые значения, а потом отдать массив классу. Но, как явствует из распечатки кода с красненькими строчками, мы уже скармливаем классу какой-то массив. И куда же засовывать кодировку?

    Разберём для примера ситуацию, когда Ваш сайт на UTF.

    В этом случае в промежутке между запуском спасательного кода и отдачей результатов его работы классу, нужно вклинить в родившийся массивчик нужный ключик, в полном соответствии с рекомендациями:

    global $mysape; define ('_SAPE_USER',"usersiteidentificator"); require_once ("./data/sape/sape.php"); require_once ("./data/sape/sape_venality_name.php");  $sape_venality_name['charset']='UTF-8'; $sape=new SAPE_client($sape_venality_name);  $mysape=$sape->return_links();

    Нужны другие ключики? Вклинивайте по аналогии.

    Когда продажные ссылки не от Сапы:

    Врядли поручиться для всех брокеров продажных ссылок, ибо клиентский код у них очень различный, но теоретически вот такая конструкция (при полном отсутствии сапы на сайте) должно помочь:

    require_once ("./data/sape/sape_venality_name.php");

    Естественно, в данном документе мы рассматриваем исключительно камуфлирование продажных ссылок на указанных в начале документа движках, а также очень на них похожих. В противном случае чтение Вами этого документа должно подкреплятся знаниями php