Маскування Зовнішніх Посилань



  • Скрипт 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