Denis Moskalets' blog » php

Яндекс-like поиск своими руками

Denya — Mon, 10 Sep 2007 23:46:16 +0000

Классная статья на Хабре про то, как быстро слепить хороший поисковйы механизм.
Про учет морфологии я думал, что все намного сложнее. Оказывается, есть неплохие простые решения.
Ну а про soundex («возможно, вы искали?») вообще первый раз слышу. Все это очень интересно

Хабрахабр: Яндекс-like поиск своими руками.

P.S. Заодно, где-то рядом там нашел линк на «правильную» реализацию PHP-функции strip_tags. Так, на всякий случай в закладки.
P.S.S. Нашел забавный блог «Коротко и ясно». Просто полезные кусочки кода... Там есть и стеммер, который у слов корни вырезает, если вариант реализации русского soundex'а. Вроде, неплохо, попробуем почитать.

Посты на схожую тематику:

WebDev / PHP / Sessions

WordPress: постоянное подключение к mysql

Denya — Sat, 07 Jul 2007 23:23:28 +0000

Сделал WordPress'у persistent-connection к MySQL.
Стало в 5 раз быстрее.

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

wp-includes/wp-db.php, 61 строка.
Меняем mysql_connect на mysql_pconnect.

Всем клиентам Нашего Хостинга — советую :-)

Посты на схожую тематику:

IBM developerWorks Россия: Изучаем PHP

Denya — Sat, 20 Jan 2007 16:54:11 +0000

На сайте IBM developerWorks Россия появился интересный мануал «Изучаем PHP».

Цель этого учебного пособия — научить вас писать на языке PHP приложения, поддерживающие workflow. Мы начнем с того, что научимся регистрироваться с определенным именем пользователя и паролем, загружать файлы на сервер из браузера, просматривать загруженные файлы. В дальнейшем для пользователей с административными полномочиями мы разработаем специальную процедуру одобрения документов для публичного доступа. В последующих двух частях этой серии (Часть 2 и Часть 3) мы рассмотрим HTTP-аутентификацию, использование потоков данных, обработку исключений и другие важные вопросы.

В первой части даются базовые понятия языка, на примерах объясняется синтаксис PHP; рассматривается создание базовой страницы, переменные, циклы и условные операторы if-then, массивы и функции, доступ к базам данных, включение файлов с помощью оператора include

Во второй части рассматривается создание сессий, передача информации между сессиями, процедура загрузки файлов на сервер из браузера и использование XML для хранения и отображения информации о файлах.

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

Короче, довольно кратко и интересно написано :) Почерпнул для себя много нового из второй-третьей части...

Посты на схожую тематику:

Как скачивать файлы из torrent-сетей, инструкция для начинающих

News / Дырка в PHP4,5

Denya — Fri, 06 Oct 2006 22:37:41 +0000

Для тех, кто не слышал — в PHP4/5 нашелся метод обходить ограничения, накладываемые директивой base_dir. А это значит, что можно написать нехороший скрипт, который будет работать с чужими файлами (ну а какие еще файлы могут быть в чужих папках?).

Решение простое. В списку запрещенных функций надо добавить symlink. Как это делалось — можно почитать в моей маленькой памятке по затыканию дыр.

Посты на схожую тематику:

Server / Памятка начинающим хостерам по затыканию дырок в PHP

Denya — Fri, 14 Apr 2006 23:41:55 +0000

Сегодня один перловщик спросил меня, а нельзя ли в PHP через suEXEC что-нибудь да как-нибудь запустить. Штудирование мануалов показало, что в случае mod_php нельзя, да и ненужно. Ну а в случае fastcgi — можно. И это хорошо, это безопасно, но сказка не о том, а о mod_php.
В мануале по PHP кроме функций exec и system, про которые я давно знал и вроде бы их запретил у себя на сервере, я нашел еще функцию popen. Я насторожился, потому что точно помнил — этой функции я в настройках PHP не запрещал!
Тут же из мануала был скопирован и запущен пример. Результат... удивил. Листинги большинства папок сервера, содержимое /etc/passwd, doc_root чужих виртуальных-серверов... Все это предстало перед моим взором :-) Конечно, виноват я. suEXEC'а нету, ведь нету же mod_php, да ну и не все файлы стояли с ограничением на чтение от all. Мой промах, признаю.

Вот код примера:


	
	error_reporting(E_ALL);

	$fp = popen($q, 'r');

	$read = '';

	while (!feof($fp))

	{

		$read .= fread($fp, 4096);

	}

	echo $read;

	pclose($fp);

	?>

Мне это не понравилось и я полез в конфиг Апача httpd.conf. В список disabled_functions я дописал popen, перезапустился... Нулевой результат. Попробовал вызвать функцию exec — вызывается.

Шоковое состояние...

Что таким образом можно сделать?
Многое. Дело в том, что PHP запускается с правами Апача. А тем временем, Апач имеет доступ ко ВСЕМ файлам ВСЕХ виртуальных хостов. Такова необходимость, иначе он не мог бы их отображать и отдавать клиентам. Соответственно, их можно удалить. Этого мало, чтобы считать эту дырку критической?

Я не знаю, как дела обстоят у крупных хостеров, но почему-то мне кажется, что у 50% эта дырка есть (проверено на примере во время написания заметки)

Как же все-таки запретить пользователям виртуального хостинга через PHP делать гадости, а именно:
A) Читать чужие файлы из чужих папок
B) Вызывать любые системные функции

Пункт A

По первому пункту все оказалось просто. Не надо включать никакой Safe Mode, бога ради. Это зло. Это очень-очень неудобно и плохо. Тем более, есть методы проще.
Виртуальный хост в Апаче создается директивой . Это естественно, что для каждого виртуального хоста вы указываете DocumentRoot. Ну так давайте же сделаем так, чтобы скрипты, запущенные из под этого виртуального хоста не могли читать файла ниоткуда, кроме как из DocumentRoot'а. А еще, давайте сделаем так, чтобы сессии для каждого виртуального хоста сохранялись в отдельных папках. Это тоже логично, зачем же все перемешивать?

Добавьте в секцию следующие строчки

<IfModule mod_php4.c>
php_admin_value open_basedir /home/username/
php_admin_value doc_root /home/username/html/
php_admin_value upload_tmp_dir /home/username/tmp/
php_admin_value session.save_path /home/username/tmp/
IfModule>

mod_php4.c замените на mod_php5.c в зависимости от версии PHP.

В этом примере DocumentRoot этого виртуального хоста:

DocumentRoot «/home/username/html»

Таким образом, первая проблема решена. Попробуйте сделать fopen(«/home/anotheruser/html/hacked.txt»,"a"); — не получится.

Пункт B

Переходим ко второму пункту.
В данном случае я совершил две ошибки: директиву disable_functions я задал там, где этого делать не стоит; да и список запрещенных функций был ДАЛЕКО неполный.

Не повторяйте мою ошибку, не пытайтесь задавать параметр disable_functions в httpd.conf отдельно для каждого виртуального хоста. У ВАС НИЧЕГО НЕ ВЫЙДЕТ! Это раньше так можно было, наверное... потому что у меня именно так и было, а я об этом где-то как-то прочитал.

disable_functions надо задавать в php.ini. Чтобы узнать, какой php.ini используется у вас, выполните в шелле следующую команду:

php -i | grep ini

И с большой вероятностью вы увидите, где лежит ваш php.ini

В нем, в районе 199 строки есть что-то вроде:

; This directive allows you to disable certain functions for security reasons.
; It receives a comma-delimited list of function names. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.
disable_functions =

Так вот. Список функций, которые НЕОБХОДИМО ОГРАНИЧИТЬ на виртуальном хостинге:
disable_functions = «popen,dl,set_time_limit,passthru,system,exec,proc_open,shell_exec,proc_close,symlink»

Это минимум. Я не уверен, что это все. Я с 90% вероятностью могу увтерждать, что ни один системный вызов на сервере не пройдет. А вот какую-нибудь еще гадость наверняка можно сделать.

UPD 2006.10.07
К списку опасных функций добавилась symlink.

Ссылки

Top 10 ways to crash PHP
Довольно интересная статья. Правда, боюсь, она немного устарела.

Посты на схожую тематику:

WebDev / PHP / Sessions

Denya — Fri, 17 Mar 2006 11:29:06 +0000

Вы никогда не сталкивались с проблемой, когда после авторизации на сайте www.domain.ru вы переходите на domain.ru, а вас не узнают?
Или вот, случай из жизни. Заходите в интернет-магазин aaa.ru, в разделе comp.aaa.ru добавляете в корзину один товар, переходите в раздел audio.aaa.ru, а корзина опять пустая. И делай чего хочешь — НЕ РАБОТАЕТ!

Я сталкиваюсь с подобными проблемами КАЖДЫЙ ДЕНЬ. Куча форумов, интернет-магазинов... да тот же news2.ru тоже имеет эту проблему.

Попробуйте зайти на news2.ru, залогиниться, а потом зайти на www.news2.ru. Вам скажут: «Привет, Гость!».

В принципе, в чем проблема — я догадался уже давно... Дело в том, что cookie, «ключик», по которому сайт вас узнает, ставится на domain.ru, домен второго уровня. А вот в домене третьего уровня (www.domain.ru) cookie уже не видится. И идут косяки.

Полистав RFC, узналось, что можно поставить кукиз на .domain.ru
Обратите внимание на ТОЧКУ перед именем домена. Это значит, что кука будет доступна как и при обращении к domain.ru, так и во всех поддоменах ТРЕТЬЕГО уровня. Это то, что было нам нужно :-)

Как в PHP это делается? Просто! Функция session_set_cookie_params:

void session_set_cookie_params ( int lifetime [, string path [, string domain [, bool secure]]] )

int lifetime — время жизни кука. Обычно session_start(); ставит куку PHPSESSID с lifetime=0. То есть после закрытия браузера кук удалится и сессия закроется. Если поставить число (в секундах) побольше, то после закрытия браузера сессия не умрет сразу, в течение этого времени можно будет открыть сайт заново, и вы останетесь залогиненным, товар в корзине интернет-магазина останется на месте.

string path — путь, начиная с которого кукиз будет действительным. «/» — значит, что прямо с корня. Кук будет виден и в http://aaa.ru/ и в http://aaa.ru/vobla
А если, например, передать функции значение path равное «/forum/», то кукиз будет «виден» только из папки и подпапок forum: http://aaa.ru/forum, http://aaa.ru/forum/comp/, но не будет «виден» из: http://aaa.ru/, http://aaa.ru/chat/

string domain — ключевой параметр, который обсуждался :-) Если вы хотите, чтоб кук был виден как по основному адресу http://aaa.ru, так и по адресу http://www.aaa.ru, то передайте функции значение параметра domain равное «.aaa.ru» и все будет тип-топ.

session_set_cookie_params() необходимо вызывать каждый раз перед session_start().

К сожалению, задать список доменов, из под которых будет виден cookie нельзя. Нельзя передать в эту функцию параметр domain типа «www.aaa.ru,comp.aaa.ru,audio.aaa.ru». Тут уже нужно думать, как быть, что делать.

А вот Perl программисты думают сами. Можно точно так же поставить кукиз на .domain.ru
А можно поставить на domain.ru и на www.domain.ru
Это уж на что хватит фантазии :-) Вот так вот.

Удачи в webdev'е, и не забывайте про такие «мелочи».

Посты на схожую тематику:

WebDev / Новые Веяния, RubyOnRails

Denya — Wed, 28 Dec 2005 16:31:52 +0000

Кто-то, прочитав заголовок, скажет: «Да какие же они новые!». Кто-то скажет: «Ну, руби, ну, рельсы. А зачем мне? PHP(Perl?) спасет мир». А кто-то просто прочитает и закроет.
По последней схеме раньше действовал и я, хотя многие уважаемые мной блоггеры (urbansheep, Clops, Maniac, julik) писали посты, употребляя загадочные термины типа RoR или Django, причем эти загадочные штуки они исключительно нахваливали. Да все как-то мимо ушей шло, не цепляло, да лень было.

А лказывается, очень интересная штуки, эти RoRы и Джанги.
По порядку.

Когда-то, давным давно, захотелось повебдевить (webdev). Выбор был небольшой, либо старик Perl, либо довольно новый на то время, активно рекламирующийся и захватывающий мир, PHP. Выбор пал на PHP, который был изучен за пару дней для удовлетворения собственного любопытства: «Динамический контент — это как?». И так делали многие, насколько я себе представляю. И даже зарабатывали на этом деньги. А кто-то и до сих пор зарабатывает. Но жизнь не стоит на месте. Это ключевой момент. Жизнь движется, все развивается. Кроме Perl и PHP есть ЕЩЕ ЧТО-ТО! И это давно надо было понять.

Даже если работать с Rails и Ruby претит принципиально рекомендуется наконец-то высунуть голову из PHP-болотца (как жаль что я это сделал так поздно) и оглядеться вокруг.

Пока еще не поздно :)
Вы программируете на PHP? PHP — это уродливый клон синтаксиса C. Хорошо конечно, но можно и по-другому.

Все цитаты на тему ruby выдернуты из поста julik'а. Очень советую почитать его пост на эту тему. Может хоть это откроет вам глаза. Попробовать RoR совсем не сложно, framework ставится легко. С полпинка. Лень ставить? Смотрите в конец поста. Try ruby!

Читать: Рельсовые войны

Кстати да, забыл сказать. Вообще, Ruby — это язык такой. Довольно молодой. Основные принципы?

Все — объект

Класс — тоже объект

Класс класса — объект (ха!)

И строка, и число — объекты, равно как True и False.

Да, null тоже объект. Кстати, его класс — объект класса Класс.

Объекты отвечают на сообщения, причем сообщения сходной семантики в классах называются одинаково

Все. Этого достаточно.

Чтобы выяснить разницу двух массивов в PHP, нужно хорошенько прочитать про все 6478 функций set arithmetic. Чтобы сделать это в Ruby, нужно отнять один массив от другого знаком минус.

...

Rails — это framework (набор библиотек, к которому надо приписать минимум кода для создания готового веб-приложения), сделанный для создания веб-сайтов с базами данных “с нуля”. Это важно — именно “с нуля”, для “напяливания” сайта на 1С оно не подойдет совершенно.

...

Но все вышесказанное нужно попробовать. По крайней мере по тому что в области архитектуры сейчас Rails — культовая система, а через год будет baseline-решением (а место Rails займут Seaside и ему подобные).

...

А хостинг — проблемой не является. Если он нужен, то он будет. А если нет — то пусть ваш клиент сделает вам одолжение и выберет среднестатистический русский хостинг, а не вас. Он вас не заслуживает.

Try ruby!
Ну что, уговорили мы вас попробовать? Тогда сделайте это в окне браузера прямо здесь и сейчас.

PS. На тему Python'а в применении к webdev'у сейчас не осилил. Лучше сделаю отдельный пост. А пока, можно прочитать про Django у Maniac'а в блоге.

Посты на схожую тематику:

WordPress / TrackBack Bug?

Denya — Wed, 28 Dec 2005 16:24:45 +0000

Однако, как всегда. У всех все работает, а у меня — через задницу.
Наплильник да помог.

ТрэкБэки от меня к другим блогам уходили в какой-то злоебучей кодировке. В заголовке прописывалась utf-8, а текст был сконверчен во что-то странное.

Итого. Файл wp-trackback.php, строки 41-50.

. . .
if ($charset)
$charset = strtoupper( trim($charset) );
else
$charset = 'ASCII, UTF-8, ISO-8859-1, JIS, EUC-JP, SJIS';

if ( function_exists('mb_convert_encoding') ) { // For international trackbacks
$title = mb_convert_encoding($title, get_settings('blog_charset'), $charset);
$excerpt = mb_convert_encoding($excerpt, get_settings('blog_charset'), $charset);
$blog_name = mb_convert_encoding($blog_name, get_settings('blog_charset'), $charset);
}
. . .

Таким образом, в заголовке у нас прописано utf-8, а текст... волшебной функцией ЗАЧЕМ-ТО конвертится из utf-8(именно это возвращает get_settings('blog_charset')) в ASCII.

Все, что надо сделать для решения проблемы, это заменить строку

$charset = 'ASCII, UTF-8, ISO-8859-1, JIS, EUC-JP, SJIS';

на

$charset = 'UTF-8, ISO-8859-1, JIS, EUC-JP, SJIS';

Ключевой вопрос — А У ДРУГИХ ПОЧЕМУ ВСЕ РАБОТАЕТ СРАЗУ, а?

UPD. Через полгода после написания записи нашелся-таки один человек, которому эти манипуляции помогли избавится от кривой кодровки в трекбеках :-) Ура!

Посты на схожую тематику: