Documentation index
- ReadMe
- Things To Know
-
- New Style Rotation
Я рад вам помочь, но в 95% случае начинается все с одного и того же: вопроса что именно не работает и как именно не работает. Поэтому дабы ускорить тот процесс, пожалуйста, сделайте следующее:
Заранее спасибо! чем больше информации - тем быстрее и качественее будет помощь :)
не показывается, белая страница и тп - значит в php.ini выключен вывод ошибок. По белому экрану я так же не могу опредлить в чем именно проблема. Надо выключить вывод ошибок и посмотреть что именно пишет.
1. Проверьте работает ли крон. Вкладка Home. Если там нет надписи “check SCJ crontab job” - следуйте к следующим пунктам. Если есть эта надпись, значит кто-то удалил нашу задачу для крона. Необходимо прописать запуск каждую минуту строки вида
cd /path_to_scj/scj/bin/; env HTTP_HOST=yourdomain.com /path_to_php/php -q cron.php
2. Если вы используете index.php Смарта убедитель, что в том же каталоге нет других index файлов, например index.html. В зависимости от настроек сервера по умолчанию при запросе урла
http://domain.com/
он может брать файл index.php или index.shtml или index.html и тд. Те если в каталоге лежит index.html - сервер грузит его вместо index.php (файл SmartCJ), те скрипт смарта не отрабатывает и хиты не считаются.
Это так же вариант, как можно посмотреть, куда вас редиректит например внешний ротатор. Поскольку каждый клик проходит много правил - единственный вариант узнать почему вас редиректит туда а не сюда - это хедеры. Итак в протоколе HTTP, говоря простым языком, существует понятие хедеров и контента. В хедерах передается служебная информация, контент - это сама страница, картинка или например флеш. 99% всех редиректов происходит с использование хедера Location. Когда браузер получает от сервера такой хедер он сразу же идет по указанному урлу.
Итак, для того что бы посмотреть куда вас редиректит скрипт надо посмотреть хедеры. Это делается следующим образом (вариантов много, но мне кажется данный наиболее простой и требующий минимальных усилий):
Location: http://site.com/
это редирект.
Так же в хедерах может быть строки типа Current-Click: и тп. Для того что бы разобрать каждую конкетную ситуацию надо именно хедеры.
Варианта 2:
1. если вы используете для подсчета кликов инклуд
Проверить это очень просто. Если вы используете include.php переименуйте его в include_scj.php и создайте файл include.php следующего содержания
<?php $f = fopen('./log.txt', a); fputs($f, date('H:i') . " {$_SERVER["HTTP_REFERER"]} \n"); fclose($f); include('include_scj.php');
потом создайте файл log.txt и chmod его 666
Скрипт очень простой, он просто пишет рефы в файл. Ставьте скрипт на час или сутки по желанию и в конце этого периода загрузите файл в эксель и отсортируйте - так будет проще посчитать сколько было хитов с нужным рефом и соотв узнать сколько было хитов с нужного домена.
2. если вы используете индекс смарта
<?php $f = fopen('./log.txt', a); fputs($f, date('H:i') . " {$_SERVER["HTTP_REFERER"]} \n"); fclose($f); include('index_scj.php');
Все. Скрипт очень простой, он просто пишет рефы в файл. Ставьте скрипт на час или сутки по желанию и в конце этого периода загрузите файл в эксель и отсортируйте - так будет проще посчитать сколько было хитов с нужным рефом и соотв узнать сколько было хитов с нужного домена.
Если надо посчитать кол-во КЛИКОВ все практически так же.
<?php if ($_COOKIE['from'] == 'trader.com') { $f = fopen('./log.txt', a); fputs($f, date('H:i') . " {$_SERVER["REMOTE_ADDR"]} \n"); fclose($f); } include('out_scj.php');
где trader.com соответственно нужный трейдер.
потом остается только посмотреть кол-во строк в лог файле за выбранный промежуток времени.
A: Клики считаются по кукам. При ИНЕ пользователю ставится кука, в которой записано от какого трейдера он пришел. При кликах считывается эта кука и соответствующему трейдеру зачисляется клик. Если при клике скрипт не может прочесть куку (ее нет) - скрипт записывает такие клики в nocookie.
Технология работы кук такова, что если кука была поставлена на странице на домене www.asd.com, то на странице с домена asd.com она НЕ будет видна. Прочесть подробнее про это можно в RFC 2965 и RFC 2109.
Что это значит в нашей ситуации: если серфер пришел к вам на страницу
http://www.site.com/
а линк к ауту
http://site.com/out.php
(те без www), то на аут куки переданы НЕ будут и клики будут засчитаны как нокуки. Что бы такого не было надо все линки на аут делать относительными.
<a href='http://site.com/out.php'>Click here</a> - НЕПРАВИЛЬНО <a href='/out.php'>Click here</a> - Правильно
Бывают частные случаи, например : У трейдера прописана Personal Page. Трейдер шлет вам как
http://host.com/
, а в Personal Page прописано
http://www.host.com/trader.html
, те теряется кука. Что бы избежать этого лучше прописывать персональную страницу как путь те просто trader.html (без http:/www..)
Надо включить в Settings - Debug out.php, кликнуть на нужной ссылке и посмотреть хедеры (как это сделать описано выше). Обычно по хедерам в целом ясно что происходит. Если не ясно - создавайте тему на форуме с хедерами, будем разбирать.
Часто сталкиваюсь со сл. ситуацией: при ошибках вебсервера (403, 404 ) редиректит на корень домена. При отсутствующей картинке на индексе браузер загружает вместо отсутствующей картинки - индекс, так мы получаем 2 ина при одном заходе.
Вариант 2: на корне лежит индекс смарта. При этом в CJ Pages так же прописан тот же индекс, получается что индекс инклудит сам себя.
В любом случае проверить это достаточно просто.
1. делаем тестовый темплейт где просто строка “тест” 2. открываем сайт как domain/?force_template=test 3. убеждаемся что в логе подсчета хитов только 1 запись с вашего ИП 4. переносим в тестовый темплейт по частям то что у вас в индексе до того момента как заметите что считает 2 раза
Вероятнее всего проблема в настройках resolv сервера. Скрипт проверяет наличие в бане этого сервиcа (http://www.uribl.com/about.shtml) запуском команды в шеле
host -tA trader.com.multi.uribl.com
Если домена нет в базе сервис должен ответить что-то вроде
Host trader.com.multi.uribl.com not found: 3(NXDOMAIN)
Если у вас отвечает например “can not connect” или “can not resolve” - надо обратиться к админу и попросить поправить resolv.conf. Как вариант показать доку (http://www.uribl.com/about.shtml) с описанием того, как это должно работать.
Проверяет очень просто: все части скрипта которые работают с траффиком инклудят файл common.php соответственно можно дописать в этот файл небольшой простой код, который будет логгировать в текстовый файл все обращения к скрипту.
$f = fopen('полный путь до log.txt', 'a'); fputs($f, date('Y-m-d H:i:s') . " file {$_SERVER['REQUEST_URI']} ref {$_SERVER['HTTP_REFERER']} ip {$_SERVER['REMOTE_ADDR']}\n"); fclose($f);
Все. В скрипте как видно 3 строки, ошибиться просто негде, потом можно посчитать кол-во запросов нужных к нужному скрипту (ин\аут) и сравнить с тем что есть в скрипте. Удобно отфильтровать напрмиер в экселе.
Сейчас гугл все больше любит сайты которые подписаны сертификатом (https). Вопрос трейда заключается в том, что по дефолту при переходе с https на http реферер не передается, соответственно траффик приходит как нореф.
В этой ситуации есть 2 выхода:
Таг добавляется в <head> вашего документа и имеет вид <meta name=“referrer” content=“unsafe-url”>
Есть следующие варианты значения тага:
Из этого нас интерисуют только origin и unsafe-url. Технически для трейда достаточно origin. Однако, учитывая что в скрипте часто используется редирет на нишу по реферу трейдера, лучше использовать unsafe-url.
Хотелось бы отметить, что это не фича какого-то скрипта, а фича современных браузеров.
99% проблем с аутом решаются просмотром дебаг хедеров out.php
Обычно по хедерам сразу ясно что как и почему, если что-то не ясно - суппорт на форуме поможет разобраться.
Если ГА не может скачать статистику с другого домена, то обычно это проблема на том домене. Например, домен на одном ИП, а днс показывает на другой, или админ закрывал каталог смарта от гугла, а за компанию закрыл от всего.
Проверить: в шеле на том серваке, где ГА, делаем wget http://anotherdomain/scj_folder/bin/scj_ex.php
и смотрим какой ответ. Должно ответить HTTP/1.1 501 Password Error, если нет - значит надо смотерть админа куда на самом деле уходит запрос.
Скрипт проверяет правильность пути основных либ, в том числе imagemagick. Проверка происходит как
exec("/path/to/imagemaick/convert --version", $output, $error);
если $error не 0 (те произошла какая то ошибка, то выводится предупреждение. Если админ считает что путь правильный то может сделать пхп файл
<?php exec("/path/to/imagemaick/convert --version", $output, $error); echo $error;
и проверить выводится ли ошибка.
В целом большинство проксей http определяются по заголовку типа X-Forwarded-For (в пхп он обозначается как HTTP_FORWARDED_FOR). При подключении Cloudflare сам запрос приходит от не от релаьного юзера, а то Cloudflare. Тут возникает 2 проблемы:
Что делать:
Так же можно без модов попробовать модификацией конфига , был интересный пример для nginx
if ($http_x_forwarded_for ~ "^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}),(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$") { set $xreal $2; } fastcgi_param HTTP_X_FORWARDED_FOR $xreal if_not_empty;
Скрипт работает под управлением IonCube Optimizer, который требует свои файлы под разные версии PHP. Когда вы в шеле запускаете установку скрипта, он определяет версию пхп с которой его запустили и скачивает файлы под нужную версию
Но бывает что на сервере стоит несоклько версий пхп, одна из них является дефолтной. Например если просто в шеле написать
user@server:~/$ php -v PHP 7.0.33-0ubuntu0.16.04.16+esm4 (cli) ( NTS )
то можно увидеть что дефолтная версия - 7.0.33, при этом для веба может быть включена другая версия.
Открываем scj/admin/test.php - PHP Version 7.4.29
Получается, что файлы скачали для 7.0, а запускаем с 7.4 , в этом случае IonCube работать не будет.
Надо просить админа унифицировать версии.
По умолчанию слейв имеет те же дески, что и мастер. Фактически он использует таблицу мастера с десками. Можно рассоединить дески мастера и слейва, что бы на слейве были те же галеры, но с другими десками. Делается это на мастере , сетинги ротации, master - slave.
Иногда люди рассоединяют дески, однако не меняют дески.
В чем минус:
- для слейва создается таблица с теми же десками, но она занимает место. - mysql кеширует и таблицу мастера и таблицу слейва, хотя по факту это одни и те же данные - занимает место в памяти
Поэтому если вы не меняете дески на слейве то лучше не рассоединять и экономить ресурсы сервера.
Во всех системах есть разделение прав пользователей. Например, рут имеет право менять все файлы, пользователь - только свои. Это сделано для того что бы разграничить права в системе и не дать например пользователю накосячить с файлами других пользователей либо вообще уронить сервер из-за того что пользователь поменял настройки сервера, не понимая что конкретно он делает.
Так же есть разграничение прав пользователя и вебсервера (апач\nginx). Например, пользователь залил скрипт (файлы) на сервер. Например, в скрипте или темполейтах есть дыра\баг и злоумышленник через эту дыру решает залить бэкдор \ эксплоит на сервак. В нормальной ситуации, когда права пользователей разделены, хакер не сможет ничего записать в файл юзера и сервер будет в безопасности, потому что по умолчанию один пользоватль (апач) не может менять файлы другого пользователя (юзера)
Иногда, для некоторых файлов, надо дать разрешение на запись другому пользователю, например, юзер дает разрешение на запись в один конкретный файл (условно log.txt) - другим пользователям (например апач), тогда на этот конкретный файл ставят пермишены 666.
Однако, иногда сервак настраивают криво, и апач может писать в любой файл любого юзера. Таким образом, если в темплейте будет дыра, то хакер сможет подменить файл скрипта и например начать редиректить себе ваш траф.
Для скрипта важно правильно находится ли пользователь за прокси, тк самый простой вариант накрутить скрипт - это делать клики с разных ИП (через прокси)
Прокси определяются по наличию хедеров в запросе (HTTP_X_FORWARDED_FOR, HTTP_FORWARDED_FOR, HTTP_CLIENT_IP).
Но часто при настройке nginx + apache не настраивают передачу хедеров. Получается что приходит запрос с ИП 22.22.22.22 на nginx , он должен этот запрос передать апачу и “дергает” апач, но поскольку апач на том же хосте что и nginx то запрос апачу приходит уже с ИП 127.0.0.1, что бы передать реальный ИП nginx добавляет поле HTTP_X_FORWARDED_FOR = 22.22.22.22 и апач уже думает что это запрос через прокси.
Что б такого не было в апаче есть моды которые автоматически обрабатывают такую ситуацию (mod_remoteip, mod_rpaf) и выставляют реальный IP при запросах с 127.0.0.1 (те когда апач стоит за nginx )