Firefox е един от най-любимите ми браузъри по много причини. Днес установих, че е възможно да се активира глобална конзола където той да започне да показва информация относно целия мрежов трафик от всичките плъгини, него самия и сайтовете. Единственното което трябва да се направи е да се стартира със параметър от командния ред -jsconsole. Как става това?
Windows 32 битов
Това е всичко. Разбира се подгответе се за потоп от информация във глобалната конзола. На мен лично ми трябва да открия проблем при обновлението му. На версия 48.0 съм и ми казва че няма обновление. Което е лъжа при положение че има 48.0.2 налична.
Понякога човек се нуждае от услуги който надежно да използва докато праща заявки нагоре-надолу към други услуги. Разбира се… не винаги може да се дебъгне точно какво и как се изпраща нагоре, особенно когато заявките са криптирани.
И тук на помощ идва HTTPBIN. Със негова помощ може доста по-лесно да се диагностицират заявките и да се преработят.
Една от любимите oперационни системи на Amazon EC2 е тяхната Amazon AMI. Разбира се няма нищо по-хубаво когато производителя на хардуера ти доставя оптимизиран софтуер за него. УВИ има няколко проблема като най-големия е, че отделни модули са доста стари. Това е защото AMI използва някакъв миш-маш от няколко операционни системи – RHEL6, RHEL7 и дори Fedora. Във моя случай nginx е версия 1.8, но за да активирам HTTP/2 се нуждая поне от версия 1.9.5 (докато актуалната е 1.10.1). Разбира се ако изчакам още някой месец може и да ме огрее… но чакам вече година и ми писна. Затова взех нещата във свои ръце и си прекомпилирах своя версия на nginx.
1. Инсталирайте nginx – ще ви спести поне писане на конфигурационни файлове. Конфигурирайте си го по свой вкус.
2. sudo yum install pcre-devel openssl-devel #библиотечки… ще ви потрябват
3. wget http://nginx.org/download/nginx-1.10.1.tar.gz
4. tar zxvf nginx-1.10.1.tar.gz
5. cd nginx-1.10.1
6. ./configure –prefix=/usr/share/nginx –sbin-path=/usr/sbin/nginx –conf-path=/etc/nginx/nginx.conf –error-log-path=/var/log/nginx/error.log –http-log-path=/var/log/nginx/access.log –http-client-body-temp-path=/var/lib/nginx/tmp/client_body –http-proxy-temp-path=/var/lib/nginx/tmp/proxy –http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi –http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi –http-scgi-temp-path=/var/lib/nginx/tmp/scgi –pid-path=/var/run/nginx.pid –lock-path=/var/lock/subsys/nginx –user=nginx –group=nginx –with-file-aio –with-ipv6 –with-http_ssl_module –with-http_realip_module –with-http_addition_module –with-http_sub_module –with-http_dav_module –with-http_flv_module –with-http_mp4_module –with-http_gunzip_module –with-http_gzip_static_module –with-http_random_index_module –with-http_secure_link_module –with-http_degradation_module –with-http_stub_status_module –with-mail –with-mail_ssl_module –with-http_v2_module –with-pcre –with-pcre-jit –with-debug –with-cc-opt=’-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’ –with-ld-opt=’ -Wl,-E’
7. make
8. /etc/init.d/nginx stop
9. sudo cp objs/nginx /usr/sbin
10. /etc/init.d/nginx start
ВАЖНО! Ако обновление ви презапише по-стара версия на nginx ще се наложи да изпълните точка 9 поне още веднъж. Защото това е един дърт пач върху оригиналния nginx.
Сега вече ако напишете nginx -V ще видите нейде:
nginx version: nginx/1.10.1
Оттук насетне е лесно. Отивате във конфигурационния файл и издирвате това:
listen 443 ssl;
за да го замените със:
listen 443 ssl http2;
Честито! Вече имате работещ nginx със http/2.
Забележка!!! Оригиналния nginx във AMI е компилиран със малко повечко опции. Липсващите са:
–with-http_xslt_module
–with-http_image_filter_module
–with-http_geoip_module
–with-http_perl_module
–with-google_perftools_module
но аз така или иначе не ги използвам тях.
Онлайн ревюта е един от начините за подпомагане на потребителите при процеса на избор на услуга или доставчик. Все пак никой не иска да работи със такива имащи една или две звезди придружени със съсипващо текстово ревю. А между другото е и инструмент за сладко отмъщение, всички знаем много примери как фирмите изведнъж стават отзивчиви при негативни ревюта из интернета.
Как обаче да се подпомогне писането на ревюта към Google Business Page? Реално след масивните обновления на интерфейса вече това е невъзможно със директен линк и потребителите са затруднени. Сега ще ви покажа как това може да се случи лесно и просто със помоща на Google Maps. За пример ще използваме магазина на нашите приятели от Aloha.bg.
За да изкараме пряк линк ние се нуждаем от 3 неща:
1. Име на страницата/бизнеса
2. ludoCID – цифри
3. LRD – цифри
Проблема обаче е вземането на ludoCID и LRD. Сега ще ви покажа как можете бързо, лесно и просто да ги вземете:
1. Отваряте Google Maps на настолен компютър
2. Намирате името на страницата/бизнеса. Във нашия случай е Aloha Bulgaria. И търсите за него.
3. Отивате където са ревютата и копирате линка.
4. Махате ,1 отзад (може да е и нещо друго) и дописвате ,3,5
5. Успех! Нашия финален линк е следния
https://www.google.bg/search?q=%D0%90%D0%BB%D0%BE%D1%85%D0%B0+(Aloha+Bulgaria),+ul.+%22Pirin%22+77%D0%91,+1680+Sofia&ludocid=1486783925008404561#lrd=0x40aa84ea6165b697:0x14a21e1a3be31051,3,5
6. Резултат от посещението на горния линк
Трик N:1 – горния линк можете да го залепите нейде из футъра на сайта със някаква интересна картинка “Напишете ни ревю във Google”
Трик N:2 – линка също така може да бъде скъсен със използване на goo.gl и да се закачи един Analytics Event за отчитане на кликовете към него.
ВАЖНО: Моля не използвайте този метод за лоши цели. Видовден винаги идва!
Общо взето се чете на един дъх и е много завладяващо. Няма да ви развалям удоволствието със разкрития какво се случва. Само става въпрос за иманяри и императори.
Снощи докато чистех един сайт от вируси намерих интересна директорна структура която просто не и беше мястото там (директория със транслации на javascript) със над 9999 файла и един добре обфускиран PHP скрипт. Разбира се любопитството ми проработи и преглеждането на файловете със шестнадесетичен редактор не даде никакъв резултат – или бяха криптирани или компресирани. Общото беше че всички файлове започваха със 0x78 0x9c. Опитите да видя какво е със file (*nix инструмент показващ типа на файла) не дадоха резултат. Но търсачките веднага разконспирираха, че това е zlib компресиран поток. Това ми разпали още повече любопитството да видя какво има във горните файлове.
Опитах да ги разкомпресирам със gunzip. Не се получи защото gzip използва zlib за компресия, но тогава файла започва със 0x1f 0x8b 0x08 и след няколко байта е самия zlib поток. Мързеше ме да си компилирам програма за разкомпресиране на zlib, можех да спретна и нещо на скриптов език. Но бях убеден че има и далеч по-лесен начин.
ИМА! Цялата магия се осъществява със следния “магически” ред: printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" |cat - zlib.raw |gzip -dc
което ми спести няколко цени минути. Има и още един подобен трик със openssl (и двата правят едно и също просто разликата е във самия синтаксис): openssl zlib -d < zlib.raw
openssl zlib -d -in zlib.raw
Резултата – видях съдържанието на файловете което беше вече първото реално доказателство за наличие на пробив във сайта. И за пореден път се убедих че от *nix-а по-голямо няма.
WordPress е много хубава CMS система и работи out-of-box. Но за да работи още по-добре се слагат разни плъгини, уиджети, модули и други благинки. Сега ще ви покажа как 2 перфектни и много известни плъгини се сбиват и правят живота ви със една идея по-труден дори при генерирането на един прост sitemap. От дълго време ползвам W3TC както и Yoast SEO. И двата плъгина са лидери във своята област и всекидневно се използват от милиони блогове. За съжаление има малка уловка при тях която се отразява на XML sitemap-a.
От известно време забелязах че сайтмапа ми веднъж се появява така:
друг път така:
Поради липса на време (и интерес) не обърнах внимание защо и как се получава това. Отделно роботите продължават да ми посещават сайта без проблем, все едно няма такъв. Обаче има проблем: веднъж когато работи сайта ми връща text/xml, друг път text/html. В момента работя разни неща за проверка на sitemap и не ми трябва просто някакъв сайтмап, ами ми трябва перфектният сайтмап.
След 30 минутно разследване се оказа че когато съм логнат винаги виждам нещата перфектно независимо колко пъти ги презаредя. Когато изляза и почистя W3TC кеша ги виждам перфектно веднъж като xml, след което при презареждане ми се сервират html файлове. Което е сигурен признак, че проблема е нейде във W3TC.
Малко предистория
W3TC има няколко режима на работа от които на мен най-ми харесва Disk: Enhanced. Във този режим готовите страници се записват на диска и със няколко ловки пренасочвания със .htaccess или nginx правила се достъпват. Това е един от най-добрите режими защото веднъж след като WordPress и PHP генерират страницата повече не се изпълнява нито ред код от тях. На практика дори WP/PHP не знаят че страницата е достъпвана след като я генерират. Единственния вариант да се достъпи е когато човек се логне или когато кеша се инвалидира. Другия вариант е Disk: Basic, но там веднъж след като се генерира страницата и се записва после достъпа пак минава през WP/PHP. Там плюса е че не се извикват всички плъгини и модули за целта и направо се връща готовата страница. На практика плъгина Hyper Cache Extended на Marto Lazarov прави същата функционалност. Другия подобен плъгин е WP Super Cache на Donncha O Caoimh, но той е малко по-комплексен и съчетава едновременно Basic и Еnhanced.
Сега Disk: Enhanced след като генерира файла го обслужва със серия правила за web server-a. Но проблема е че по дефиниция той приема че всички кеширани файлове са text/html докато във моя случай трябва да връща text/xml. За да бъде хаоса пълен тези файлове не съществуват физически на диска а WordPress ги виртуализира през едно негово API. Yoast SEO ги генерира от базата данни и ги връща на клиента. Затова и W3TC ги прихваща.
Разбира се W3TC има правила при които може да се изключи файл от кеширането. При мен просто във Performance -> Page Cache -> Never cache the following pages:
При вас разбира се може файловете малко да се различават. Затова отворете sitemap_index.xml и добавете във горния списък необходимите файлове.
Разбира се всичко зависи от настройките на плъгините и на практика ставате жертва на обстоятелствата. И двата плъгина работят чудесно по отделно, но при определени настройки нещата се чупят когато са заедно. Разбира се това работи във моя случай. Обаче ако сте активирали минифицирането и конкатинирането на файловете е напълно възможно също да счупите генерирането на сайтмап.
Извода е, че колкото по-голям и комплексен е даден плъгин толкова по-голяма е вероятността да повреди нещо друго. И винаги проверявайте какво се случва след плъгините. Понякога малки и незначителни на вид неща имат катастрофални последици.
Днес докато разглеждах сайта на доставчика ми (Networx) от мобилно устройство за да открия тарифата за безжичен интернет забелязах че докато зарежда за части от секундата видях текст “стоматолог в русе”. Но когато страницата се зареди вече нямаше такъв текст. Разбира се любопитството ми проработи и когато седнах на компютър направих нова проверка.
Резултата беше категоричен. Линк има във кода:
Но във DOM линка изчезва:
Тук вече любопитството ми заработи на пълни обороти. Има няколко начина да се скрие линк като се направи невидим – като се сложи за цвят цвета на фона, като се направи със много малък шрифт, като се скрие зад друг елемент и още няколко подобни похвати описани по-подробно на линка тук. Разбира се описано е много добре:
Hiding text or links in your content to manipulate Google’s search rankings can be seen as deceptive and is a violation of Google’s Webmaster Guidelines.
Понеже Google не са всемогъщи те имат една форма за подаване на сигнал към екипа за уеб спам която се намира тук. Разбира се никой не е открил топлата вода. Подобни условия имат Bing и Yandex
Но това са разни CSS похвати които са сравнително лесно може да се открият. Във моя случай текста просто изчезваше което говореше за използване на JavaScript код. За щастие целия текст е обграден от един span елемент с много специфичен идентификатор което предполага използването му за почистването. Тук вече късметът ми изневери малко. Сайта имаше 20 JS скрипта и 11 CSS файла и не ми се търсеше всичко файл-по-файл. За мое щастие във инструментите за разработчици има възможност да се търси текст във всички файлове. Така лошия код много лесно беше разгадан:
Хмм… Разгледах няколко страници от сайта им и на всички намерих горния код. На пръв поглед изглежда някой е хакнал моя интернет доставчик като му е сложил 4 реда нейде из WordPress темата. Една проверка във OpenSiteExplorer за линка показа, че и още един сайт има същия линк: Проблема е че RuseNews също е на Networx и изглежда и той беше пострадал. Втория проблем е, че OSE работи доста бавно за откриване на нови линкове поради специфика на самия инструмент. Затова една бърза проверка във OpenLinkProfiler разкрива малко повече подробности:
Явно не само Networx са пострадалите от тази линкбилдинг техника. Уви тази техника е непозволена и може да доведе до наказания на всички сайтове участващи във схемата. Аз няма да рапортувам сайтовете във тази порочна схема, но не мога да гарантирам че някой читател няма да направи това. Освен това нарочно използвам снимки за да не им правя неволен линкбилдинг.
Затова винаги си проверявайте сайтовете през някакъв период от време за изходящи и входящи линкове. Понякога няколко минути работа може да доведат до резултати многократно надхвърлащи очакванията.
